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