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