آیا دارای build روزانه هستید؟

build روزانه‌ای که جوئل اسپالسکی از آن صحبت می‌کند، در واقع مخصوص تیم‌هایی است که به طور مداوم در حال بهبود برنامه‌های جاری خود می‌باشند. این به معنی وجود تیم‌های نرم‌افزاری است که کار اعضای آن فقط و فقط کدنویسی و توسعه نرم‌افزار بر اساس roadmap های تعیین شده باشد. در چنین تیم‌هایی، شما همیشه لازم است مطمئن باشید که دارید روی یک نسخه سالم از نرم‌افزار کار می‌کنید.

برنامه‌نویسانی که باعث شکست build می‌شوند، چیزی مثل این را بدهید تا حداقل برای همان روز شرمگین باشند!

اجازه بدهید موضوع را با یک مثال توضیح بدهم: وقتی شما از یک نرم‌افزار source control استفاده می‌کنید، هر زمان بخواهید روی فایل سورسی تغییری بدهید باید آن فایل را تحویل بگیرید (check out) و هر زمان که کارتان بر روی آن فایل به اتمام برسد آن را تحویل می‌دهید (check in) بعد از اینکه همه فایل‌ها check in شوند، در واقع نسخه جدیدتری از نرم‌افزار را خواهید داشت (که یا feature ای به آن اضافه شده یا bug برطرف شده یا هر دو) البته ممکن است بسته به نوع نرم‌افزار source control و نحوه مدیریت شما بر کد مراحل دیگری نیز نیاز باشد، مثلاً اگر در تیم شما branch هایی از سورس اصلی ایجاد شده باشد، در نهایت لازم است کدها را ادغام (merge) کنید. صرفنظر از روش کار با سورس‌ها، فایل‌های نهایی که ایجاد می‌شوند ممکن است باعث fail شدن پروسه build بشوند! یعنی برنامه‌نویسی کدی را check in کرده که روی سیستم خودش درست بوده و کار می‌کرده اما باعث fail شدن build‌ محصول نهایی شود و محصول نهایی دیگر یک نرم‌افزار سالم و stable (چنانکه در نسخه قبل بوده) نباشد. به این مساله شکستن buildهم گفته می‌شود. جوئل در این مورد پیشنهادی دارد و آن استفاده از build روزانه است. build روزانه یعنی build کامل روزانه اتوماتیک تمام source. خودش درباره پیشنهاد build روزانه برای رفع مساله شکستن build چنین توضیح می‌دهد:

"شكستن بیلد آنقدر بد (و رایج) است كه درست كردن بیلد روزانه کمک می‌كند كه چنین موضوعی ناشناخته نماند. در تیم‌های بزرگ، یک راه این كه مطمئن شوید كه چنین مشكلاتی در اولین فرصت برطرف شوند، این است كه بیلد روزانه را هر روز، هنگام ناهار انجام دهید.
همه تمامی check in هایی را كه می‌توانند قبل از رفتن به ناهار انجام می‌دهند. بیلد، زمانی كه همه برگشتند تمام شده است. اگر كه همه چیز درست است، كه فبحال! آخرین نسخه سورس توسط همه check out شده و كار ادامه پیدا می‌كند. اما اگر كه عمل بیلد با موفقیت روبرو نشده باشد، افراد با نسخه سالم قبلی به كار خود ادامه می‌دهند."

مزایای build روزانه

اسپالسکی در نوشته دیگری به معرفی مزایای build‌ روزانه و روش اجرایی کردن آن می‌پردازد. خلاصه‌ای از آن مزایای build روزانه از نظر جوئل اسپالسکی به شرح زیر هستند:

• اگر باگی fix شده باشد، tester ها خیلی سریع آخرین نسخه را دریافت می‌کنند و می‌توانند با تست مجدد بررسی کنند که آیا باگ واقعا fix شده یا خیر؟
• توسعه‌دهنده‌ها خیالشان راحت است که کدی که تغییر دادند باعث شکسته شدن 1024 تا نسخه قبلی نرم‌افزار نشده است.
• توسعه‌دهنده‌هایی که قبل از زمان برنامه‌ریزی شده برای build روزانه کدشان را check in می‌کنند مطمئن هستند که کدی که تغییر دادند باعث شکست build نمی‌شود (شرایطی پیش نمی‌آید که بقیه نتوانند کل source را کامپایل کنند) این حالت معادل صفحه آبی مرگ برای کل تیم نرم‌افزاری است!
• گروه‌های خارج از تیم فنی، مثل تیم بازرگانی، تست کننده‌های نسخه بتا و ... می‌توانند از یک نسخه‌ روزانه که تا حد قابل قبولی stable است تا مدتی استفاده کنند.
• با نگه داشتن history کل build های روزانه، وقتی که یک خطای عجیب و غریب که مشخص نیست از کدام check in به بعد ایجاد شده به وجود می‌آید. با یک جستجو بر روی build ها می‌توانید متوجه شوید که خطا از کدام build به بعد ایجاد شده و اگر از یک نرم‌افزار source control‌ قوی استفاده کنید حتی می‌توانید مشخص کنید که کدام check in‌ باعث بروز این خطا شده است.
• وقتی tester مشکلی را گزارش می‌کند که برنامه‌نویس گمان می‌کند قبلاً fix شده، tester می‌تواند شماره build روزانه را هم که خطا در آن دیده شده به برنامه‌نویس اعلام کند، برنامه‌نویس می‌تواند تاریخ کدی که باگ را fix کرده بوده با تاریخ build باگ دار مقایسه کرده و از صحت fix اطمینان حاصل کند.