وقتی نیاز به به‌روزرسانی دارید اما زمان ندارید چالش‌های Deploy در وسط توسعه
مثلاً قراره امروز دمو بدی، ولی بخش پرداخت هنوز نصفه‌ست. باگ checkout هم هنوز فیکس نشده توسعه هنوز تموم نشده بعضی بخش‌ها نصفه‌کاره‌ان فیچرها کامل نیستن. اما تیم تحت فشاره که سریع یه نسخه جدید رو منتشر کنه. چرا؟ چون یک باگ حیاتی باید سریع رفع بشه. یا باید برای یک دمو چیزی آماده باشه.
یا شاید یه موعد تحویله و کاریش نمی‌شه کرد. اینجاست که تیم‌ها سراغ استقرار وسط توسعه می‌رن. تصمیمی پرریسک که گاهی نتیجه می‌ده و گاهی هم فاجعه می‌سازه.
چرا این اتفاق می‌افته؟
فشار زمانی
وعده‌هایی که زودتر از موعد داده شده
تحویل به مشتری در حین توسعه
یا حتی ناهماهنگی بین تیم‌ها
اما مهم‌تر از دلیل، نتیجه است: کدی که آماده نیست، در معرض استفاده قرار می‌گیره. این یعنی رفتار کاربرها، کسب‌وکار و حتی اعتبار برند می‌تونه تحت تاثیر قرار بگیره.
وقتی کد ناتمام وارد محیط واقعی می‌شه، خطراتی جدی در کمینه:
کاربران با رفتارهای نصفه‌نیمه مواجه می‌شن
باگ‌های جدید ظاهر می‌شن
تست‌ها ناقصن یا بی‌اثر
قابلیت rollback ممکن نیست چون نقطه بازگشت واضحی نداریم
اعتماد به نسخه‌های بعدی کاهش پیدا می‌کنه
در برخی موارد، توسعه‌دهندگان سعی می‌کنن با توضیح در changelog یا راهنمای کاربر، انتشار ناقص رو بپوشونن. ولی وقتی خطا از درون سیستم بلند شه، توضیح چندان فایده نداره.
راهکارهایی برای استقرار امن در شرایط ناتمام
گاهی واقعاً نمی‌شه استقرار رو عقب انداخت. پس باید جوری استقرار بدیم که بخش‌های ناپایدار تجربه کاربر رو خراب نکنن:
استفاده از Feature Flag
با این روش می‌تونیم بخش‌هایی از کد رو روی سرور داشته باشیم اما برای کاربر فعال نباشن. مثل سوئیچ‌هایی که هر وقت آماده بودن، روشنشون کنیم. ابزارهای open-source زیادی برای این کار وجود دارن که به راحتی قابل استفاده هستن.
محیط‌های staging واقعی و فعال
قبل از هر استقرار، جایی برای تست واقعی وجود داشته باشه که تیم بتونه همه‌چی رو شبیه‌سازی کنه بدون اینکه چیزی وارد production بشه. محیط‌هایی که بیشترین شباهت رو به prod دارن، بهترین کارایی رو دارن.
لاگ‌گیری و مانیتورینگ لحظه‌ای
اگه قراره چیزی رو نصفه منتشر کنیم، باید بتونیم سریع بفهمیم کجا خراب شده، قبل از اینکه کاربر بفهمه. لاگ و مانیتورینگ اینجا نجات‌دهنده‌ست. ابزارهایی مثل Loki یا Grafana به تیم‌ها کمک می‌کنن ریزترین ناهنجاری رو ثبت و بررسی کنن.
استقرار مرحله‌ای (Rolling Deploy)
به جای اینکه همه‌ی سرورها یک‌باره آپدیت بشن، بهتره به‌صورت تدریجی و نسخه‌بندی‌شده این کار انجام بشه. اینطوری اگر باگ بزرگی رخ داد، تاثیرش محدود می‌مونه و rollback سریع‌تر انجام می‌شه.
نگهداری نسخه‌های پایدار
داشتن snapshotهایی از نسخه‌های پایدار قبلی، برای rollback ضروریه. استقرار ناپایدار اگه نتونه سریع به نسخه سالم برگرده، عملاً بحران‌زاست.
تصور اشتباه تیم‌ها
بعضی تیم‌ها فکر می‌کنن «می‌دونیم چی کار کردیم، پس می‌دونیم چی deploy می‌کنیم». ولی واقعیت اینه که وقتی وسط توسعه‌ای، هیچ‌چیز قطعیت نداره یک refactor ساده می‌تونه یه endpoint رو از کار بندازه. یا یک commit نیمه‌کاره روی کل فرایند login تاثیر بذاره.
یا گاهی دیده شده که تیم بدون سینک با تیم QA استقرار می‌ده، درحالی‌که test caseهای اون بخش هنوز آماده نشده. نتیجه؟ انتشار ویژگی‌ای که هیچکس مطمئن نیست واقعاً کار می‌کنه یا نه.
آیا این ریسک ارزشش را دارد؟
گاهی باید بین دو گزینه یکی را انتخاب کرد: تأخیر در ارائه یا استقرار ناپایدار. تصمیم سختی‌ست. اما تجربه نشان داده تیم‌هایی که بدون ابزار مناسب سراغ انتشار کد ناتمام می‌روند، اغلب بیشتر از چیزی که جلو افتاده‌اند، عقب می‌افتند. شاید کارفرما خوشحال بشه که زودتر فیچر رو دید، ولی بعدش با موجی از نارضایتی کاربر مواجه می‌شه.
زیرساختی که به شما این امکان رو می‌ده که:
بخش‌هایی از کد رو فعال/غیرفعال کنی
لاگ‌گیری زنده داشته باشی
rollback ساده انجام بدی
دقیقاً توی این لحظه‌ها تفاوت ایجاد می‌کنه. نه با ابزار خاص، بلکه با فراهم‌کردن بستری که این روش‌ها رو پشتیبانی کنه.
زیرساخت‌های مدرن معمولاً ابزارهایی برای مدیریت deployment pipeline، محیط‌های موازی برای staging و حتی پشتیبانی از rollout مبتنی بر ترافیک دارن.
فرض کنیم دو تیم توسعه، در حال کار روی یک پلتفرم فروشگاهی هستن. هر دو تیم مجبور می‌شن به‌دلایلی، وسط توسعه، فیچری مرتبط با پرداخت رو منتشر کنن.
تیم اول، سریع و بدون تست، کد رو deploy می‌کنه. بلافاصله کاربران گزارش می‌دن که سبد خرید کار نمی‌کنه. rollback سخت و دستی انجام می‌شه.
تیم دوم، از feature flag استفاده می‌کنه، نسخه production هیچ‌وقت متوجه تغییر ناقص نمی‌شه. بعد از تکمیل توسعه، فقط flag رو روشن می‌کنن.
همه توسعه‌دهنده‌ها این شرایط رو تجربه کردن
کدی که آماده نیست اما باید بره بالا. چیزی که ممکنه خراب کنه ولی نمی‌شه نگهش داشت. فرق تیم حرفه‌ای با تیم بی‌برنامه توی همین لحظه‌هاست.
زیرساخت‌هایی مثل برنت، با فراهم‌کردن بستر امن برای استقرار مرحله‌ای، مانیتورینگ زنده، و طراحی‌های انعطاف‌پذیر، کمک می‌کنن این تصمیم سخت، حداقل کم‌ریسک‌تر بشه. اینکه بتونی وسط توسعه هم استقرار داشته باشی بدون اینکه کل سیستم بلرزه.
تیمی که زیرساخت مناسبی داره، حتی وقتی مجبور به انتشار ناپایدار می‌شه، می‌تونه اعتماد کاربر رو حفظ کنه. اونایی که ندارن، فقط دعا می‌کنن خراب نشه.
