خط لولهای که تیم به آن اعتماد میکند
خط لولهٔ یکپارچهسازی و تحویل داشتن، امروز تقریباً همهجا هست. خط لولهای داشتن که تیم واقعاً به آن اعتماد کند، خیلی کمتر.
تفاوت را با یک سؤال میشود سنجید: وقتی خط لوله قرمز میشود، واکنش اول تیم چیست؟
اگر جواب «ببینیم چه چیزی شکسته» است، خط لوله سالم است. اگر جواب «دوباره اجرا کن، احتمالاً همان مسئلهٔ همیشگی است» است، خط لوله دیگر یک دروازه نیست؛ یک مانع تشریفاتی است که دور زده میشود.
این مقاله دربارهٔ همان تفاوت است.
بیلد بازگشتپذیر، پیش از هر چیز دیگر
یک بیلد از یک commit مشخص، باید هر بار همان خروجی را بدهد. اگر ندهد، هیچچیز دیگری در این مقاله معنا ندارد — نه تست، نه استقرار، نه بازگشت به نسخهٔ قبل.
سه چیزی که این را میشکنند:
فایل قفل وابستگیها در مخزن نیست. بیلد امروز و بیلد هفتهٔ پیش دو مجموعهٔ متفاوت از کتابخانه دارند. این تنها متداولترین علت «روی ماشین من کار میکند» است، و همزمان یک مسئلهٔ امنیتی — امنیت وابستگیها.
بیلد به حالت ماشین وابسته است. نسخهٔ ابزاری که روی سرور بیلد نصب است، پوشهٔ کش، متغیری که کسی دستی تنظیم کرده. جوابش محیط بیلد ایزوله است — که یکی از دلایل اصلی استفاده از کانتینر در همین مرحله است.
تنظیمات محیط داخل خروجی بیلد است. خروجی باید یک بار ساخته شود و در همهٔ محیطها همان باشد؛ آنچه عوض میشود پیکربندی است، نه خروجی. اگر برای تولید دوباره بیلد میکنید، چیزی که تست کردهاید آن چیزی نیست که منتشر میکنید. مفصل در محیطها و پیکربندی.
زمان، که همهچیز دیگر تابع آن است
عددی که بیش از هر چیز دیگری رفتار تیم را تعیین میکند: چقدر طول میکشد تا بفهمم تغییرم چیزی را شکسته؟
زیر ده دقیقه، توسعهدهنده منتظر میماند و نتیجه را میبیند. بالای بیست دقیقه، سراغ کار بعدی میرود و وقتی نتیجه بیاید ذهنش جای دیگری است. بالای چهل دقیقه، تیم شروع میکند به دستهکردن تغییرات — و آن لحظهای است که یکپارچهسازی «مستمر» دیگر مستمر نیست.
سه کار که بیشترین اثر را دارند:
تقسیم به دو مرحله. یک مرحلهٔ سریع در هر تغییر (کامپایل، تست واحد، تحلیل ایستا، اسکن وابستگی) و یک مرحلهٔ کامل پیش از ادغام یا شبانه (تست یکپارچگی، سرتاسری، کارایی).
اجرای موازی. تستهایی که به هم وابسته نیستند نباید پشت سر هم اجرا شوند. و تستی که به ترتیب اجرا وابسته است، خودش یک باگ است — دادهٔ تست.
کش کردن وابستگیها. ساده، و معمولاً نصف زمان بیلد را برمیگرداند.
شکست ناپایدار: مهمترین چیزی که باید جدی بگیرید
تستی که گاهی سبز و گاهی قرمز است، بدترین چیزی است که میتواند در خط لوله باشد — بدتر از تست نداشتن.
دلیلش رفتاری است: وقتی قرمز شدن گاهی بیمعنا باشد، آدمها یاد میگیرند قرمز را نخوانند. و آن روزی که قرمز واقعی است، همان واکنش را میگیرد: «دوباره اجرا کن».
سیاستی که پیشنهاد میکنیم و خودمان اجرا میکنیم:
تست ناپایدار در همان روز یا درست میشود یا از مجموعهٔ اصلی خارج میشود و بهعنوان یک آیتم با مسئول ثبت میشود. حالت سومی وجود ندارد.
خارج کردن یک تست، خوشایند نیست. ولی تستی که کسی به نتیجهاش اعتماد ندارد، عملاً از قبل خارج شده — فقط هنوز وقت همه را میگیرد.
ترتیب مراحل: ارزانترین دروازه اول
هر مرحلهای که کندتر است، باید دیرتر بیاید. ترتیبی که در عمل جواب میدهد:
۱. کامپایل و بررسی نوع — ثانیهها. اگر اینجا شکست، بقیه بیمعناست. ۲. قالببندی و تحلیل ایستا — ثانیهها. این دو باید خودکار باشند، نه موضوع بحث در بازبینی کد. ۳. تست واحد — دقیقه. ۴. اسکن وابستگی و راز — سریع، و جلوی گرانترین اشتباهها را میگیرد. ۵. ساخت خروجی — یک بار، برای همهٔ محیطها. ۶. تست یکپارچگی — دقایق. ۷. استقرار روی محیط آزمون — خودکار. ۸. تست سرتاسری روی همان محیط — محدود به مسیرهای درآمدزا. ۹. تست کارایی سبک — که تخطی از بودجه را همان روز پیدا کند.
بند چهارم را دستکم نگیرید. اسکن راز — بررسی اینکه کلید و رمزی وارد مخزن نشده — چند ثانیه طول میکشد و جلوی اشتباهی را میگیرد که پاک کردنش از تاریخچه روزها کار است. جزئیات در مدیریت رازها.
پیام شکست، که کسی به آن فکر نمیکند
خط لولهای که فقط میگوید «بیلد شکست» و لینکی به هزار خط لاگ میدهد، وقت تلف میکند.
سه چیز باید در همان اعلان باشد: کدام مرحله، کدام تست یا بررسی، و تفاوت انتظار با واقعیت. اگر تیم باید لاگ کامل را باز کند تا بفهمد چه شده، هر شکست چند دقیقهٔ اضافه هزینه دارد — ضربدر تعداد شکستها در سال.
دروازهها: کدامها اجباری باشند
هر بررسیای نباید بیلد را متوقف کند. تفکیک عملی:
متوقفکننده: کامپایل، تست واحد و یکپارچگی، آسیبپذیری بحرانی، راز پیداشده در کد.
فقط گزارش: پوشش تست، هشدارهای سبک کد، آسیبپذیری کمشدت در وابستگیای که به تولید نمیرود.
مرزی که مکرراً اشتباه گذاشته میشود، پوشش تست است. آستانهٔ اجباری پوشش، تیم را وادار میکند تست بیارزش بنویسد تا عدد بالا برود. آنچه واقعاً کار میکند، قاعدهٔ هر باگ یک تست است، نه یک درصد.
و در نهایت: خط لوله هم کد است
فایل تعریف خط لوله باید در همان مخزن باشد، در بازبینی بیاید، و تغییرش ثبت شود. خط لولهای که در رابط گرافیکی ابزار تنظیم شده و کسی نمیداند دیروز چه تغییری کرده، همان مسئلهای را دارد که سرور دستیتنظیمشده دارد.
و مثل هر زیرساخت دیگری، مالکیتش باید مکتوب باشد — وگرنه به چیزی تبدیل میشود که فقط یک نفر میفهمدش، و آن یک نفر روزی مرخصی میرود. مستندسازی زیرساخت دربارهٔ همین است.