زمان مطالعه: حدود ۶ دقیقه
مخاطب: تیم‌های فنی، توسعه‌دهندگان، مدیران پروژه و محصول
خلاصه مقاله
گاهی نسخه هنوز کامل نیست، فیچرها نصفه‌اند، باگ‌ها فیکس نشده، اما فشار بیرونی اجازه نمی‌ده منتظر بمونی. «باید همین امروز منتشرش کنیم!» اگر این موقعیت برات آشناست، بدون تنها نیستی. ولی سؤال مهم اینه: آیا استقرار در میانه توسعه قابل‌پذیرشه؟ یا فقط داریم بحران رو جلو می‌ندازیم؟
در این مقاله، سناریوهای پرتکرار استقرار ناپایدار، ریسک‌های احتمالی، راهکارهای امن، و تجربه‌های واقعی از پروژه‌ها رو بررسی می‌کنیم. آخر مقاله هم چک‌لیستی آماده کردیم که اگر مجبور شدی وسط توسعه چیزی رو deploy کنی، حداقل کم‌ریسک‌ترین حالت ممکن رو داشته باشی.
چرا این اتفاق می‌افته؟
- فشار برای رفع فوری یک باگ حیاتی
- موعد تحویل به مشتری یا سرمایه‌گذار
- نیاز به آماده بودن برای دمو یا جلسه مهم
- وعده‌هایی که زودتر از واقعیت داده شدن
- عدم هماهنگی بین تیم‌ها (مثلاً dev و QA)
این دلایل باعث می‌شن تیم‌ها تصمیم بگیرن «با همین چیزی که داریم بریم بالا»، حتی اگه: بعضی فیچرها ناقص باشن، باگ‌ها هنوز پابرجا باشن، تست‌ها کامل نشده باشن، ریسک‌های پنهانی استقرار ناپایدار، کاربران با رفتارهای غیرمنتظره مواجه می‌شن، باگ‌های جدید به تجربه کاربری ضربه می‌زنن، تست‌ها بی‌اثر یا ناقص می‌مونن، rollback سخته چون snapshot مشخصی نداریم، اعتماد به نسخه‌های بعدی کاهش پیدا می‌کنه و تیم توسعه هم وارد حالت اضطراری می‌شه، چون باید «خراب‌کاری رو ترمیم کنه» حالا بدترین حالت، وقتیه که حتی متوجه نمی‌شی چه چیزی منتشر شده، چون QA هنوز تستش نکرده و تیم dev هم commit نیمه‌کاره داشته.
چطور وسط توسعه، امن استقرار بدیم؟
استفاده از Feature Flag
بخش‌هایی از کد که هنوز آماده نیستن، روی سرور deploy می‌شن ولی برای کاربر خاموش می‌مونن. مثل کلیدی که فقط وقتی آماده بودی روشنش می‌کنی. ابزارهای open-source و سرویس‌های feature toggle زیادی برای این کار هستن.
داشتن محیط staging واقعی
محیط staging فقط یه اسم نباشه. باید کاملاً شبیه production باشه. همه چیز قبل از استقرار واقعی باید در این محیط تست بشه. اینجا جاییه که متوجه می‌شی کجای کارت ناتمومه.
لاگ‌گیری و مانیتورینگ لحظه‌ای
استقرار نصفه یعنی ممکنه چیزهایی خراب شن. اما اگه مانیتورینگ دقیق مثل Loki، Promtail یا APM فعال باشه، حداقل می‌فهمی چی کجا خراب شده قبل از اینکه کاربر بفهمه.
استقرار مرحله‌ای (Rolling Deploy)
نسخه رو به تدریج منتشر کن. به جای اینکه همه‌ی سرورها هم‌زمان آپدیت شن، فقط بخشی رو آپدیت کن، ببین چطور رفتار می‌کنه. اگه مشکلی بود، سریع rollback کن.
تصور و اشتباه رایج اینه که ما خودمون کد زدیم، می‌دونیم چی داریم deploy می‌کنیم! واقعیت اینجاست که وقتی وسط توسعه‌ای، هیچ‌چیز قطعیت نداره. یه refactor ساده می‌تونه endpoint رو بشکنه. یا یه commit بی‌سینک با QA، کل login رو خراب کنه.
و اما دوتیم، دو رویکرد...
تیم اول: انتشار بدون ابزار
کد پرداخت هنوز کامل نیست، ولی تیم مجبور می‌شه دمو رو آماده کنه. مستقیم deploy می‌کنن. سبد خرید می‌ریزه. rollback سخت و دستی. کاربرها ناراضی، تیم پرتنش.
تیم دوم: انتشار با feature flag
کد روی سروره ولی برای کاربر خاموشه. هیچ اختلالی پیش نمیاد. بعد از تکمیل QA، فقط flag روشن می‌شه. هیچ بحرانی اتفاق نمی‌افته.
تست پیشنهادی برای تیم شما
آیا تیم شما می‌تونه بدون تماس با QA، یه feature غیرفعال رو منتشر کنه؟
اگه نه، زیرساخت‌تون هنوز برای استقرار ناپایدار آماده نیست.
زیرساخت‌های مدرن مثل برنت، به تیم شما امکان می‌دن که:
- Featureها رو به‌صورت تدریجی و امن rollout کنید
- لاگ‌ها و مانیتورینگ real-time رو روی همه سرویس‌ها داشته باشید
- rollback با یک snapshot قابل انجام باشه
- محیط staging واقعاً شبیه production باشه
این یعنی حتی وقتی مجبور به تصمیم سخت شدی، حداقل بدون ریسک بزرگ می‌تونی منتشر کنی.
همه ما اون لحظه رو تجربه کردیم که کد هنوز کامل نیست، ولی باید بره بالا...
تیم حرفه‌ای و تیم بی‌برنامه، تفاوتشون تو همین لحظه‌ها مشخص می‌شه. یکی با ابزار مناسب، بحران رو کنترل می‌کنه. اون یکی، فقط دعا می‌کنه که خراب نشه. زیرساخت مناسب مثل چتر نجاته شاید همیشه استفاده نشه، ولی وقتی نیاز داری، بود و نبودش سرنوشت تیم رو مشخص ميکنه.
