Software Deployments | استقرار نرم‌افزار

استقرار نرم‌افزار عملی است که نسخهٔ ساخته‌شده را به محیطی می‌برد که انسان یا سیستم دیگر بتواند آن را اجرا کند: سرور تولید، استیجینگ، یا مسیر انتشار موبایل. با استقرار، کد از فایل مخزن به محصول در حال اجرا تبدیل می‌شود. برای تیم محصول، نحوهٔ استقرار تعیین می‌کند با چه سرعت و ایمنی می‌توان تغییر داد، اندازه گرفت و در صورت مشکل برگشت. این مفهوم عملیات انتشار و دیپلوی است — نه مراسم اسکرام، نه برنامه‌ریزی اسپرینت، و نه نقش اسکرام مستر.

از آرتیفکت تا سیستم زنده

بیلد خروجی کامپایل یا بسته‌بندی‌شده است؛ یک آرتیفکت. استقرار آن آرتیفکت را روی محیط هدف می‌نشاند، پیکربندی و در صورت نیاز پایگاه داده را به‌روز می‌کند، ترافیک را به نسخهٔ جدید می‌سپارد، و سلامت را چک می‌کند. در عمل واژهٔ دیپلوی کل این رویه را هم پوشش می‌دهد، به‌ویژه وقتی پایپ‌لاین خودکار همان مسیر را برای هر تغییر تکرار می‌کند.

دیپلوی تغییر روی سیستم زنده است؛ به همین دلیل تمرین حرفه‌ای حول محدود کردن شعاع آسیب و بازیابی سریع شکل می‌گیرد. تیمی که دیپلوی را رویداد ترسناک ماهانه می‌بیند با تیمی که چند بار در روز با گام‌های کوچک منتشر می‌کند، ظرفیت یادگیری کاملاً متفاوتی دارد.

بیلد، دیپلوی، ریلیز، دلیوری؛ چهار واژه، چهار معنا

بیلد آرتیفکت می‌سازد. دیپلوی آرتیفکت را روی محیط می‌گذارد. ریلیز قابلیت را برای کاربر فعال و قابل استفاده می‌کند؛ گاهی همان لحظهٔ دیپلوی، گاهی خیلی بعدتر پشت فلگ. دلیوری پیوسته توصیف قابلیت تیم است که تقریباً هر تغییر آماده‌ٔ استقرار باشد. اشتباه رایج یکی دانستن این چهارتاست.

جدا کردن دیپلوی از ریلیز برای محصول طلاست: مهندسی می‌تواند کد را تاریک روی تولید ببرد؛ محصول وقتی پشتیبانی، بازاریابی و آمادگی تجربه رسید فلگ را باز می‌کند. دیپلوی تصمیم فنی اجراست؛ ریلیز تصمیم محصولی در معرض کاربر قرار دادن است.

مسیر محیط‌ها: توسعه، استیج، تولید

محیط توسعه جای شکستن و آزمایش محلی یا سندباکس است. استیجینگ شبیه تولید با داده و پیکربندی نزدیک به واقعیت است تا کل محصول قبل از کاربر واقعی آزموده شود. تولید سیستمی است که کاربر به آن وابسته است. بعضی تیم‌ها محیط پیش‌نمایش برای هر شاخه می‌سازند تا بازبینی در مرورگر ممکن شود.

برای طراح، استیجینگ معمولاً اولین جایی است که فیچر ساخته‌شده را در برابر طرح می‌توان دید. بازهٔ بازبینی طراحی قبل از خروج از استیج کوتاه است؛ بعد از تولید، اصلاح می‌شود follow-up. دانستن اینکه تغییر کجای مسیر است به زمان‌بندی QA طراحی کمک می‌کند.

استراتژی جایگزینی نسخه

استقرار recreate نسخهٔ قدیم را متوقف و جدید را بالا می‌آورد؛ ساده است و کوتاهی قطعی ممکن دارد. rolling سرورها را تدریجی عوض می‌کند تا سرویس کامل نخوابد. blue-green دو محیط تولید هم‌سان نگه می‌دارد و ترافیک را یکجا سوئیچ می‌کند؛ برگشت یعنی سوئیچ معکوس. canary ابتدا سهم کوچکی از کاربر یا سرور را می‌گیرد، متریک را می‌بیند، بعد سهم را باز می‌کند.

فیچر فلگ استراتژی زیرساختی محض نیست اما تصویر را عوض می‌کند: کد برای همه دیپلوی می‌شود و قابلیت برای گروه انتخابی روشن می‌گردد. rollout تدریجی ابزار محصول می‌شود نه فقط عملیات سرور. هرچه هزینهٔ قطعی بالاتر باشد، تیم معمولاً از recreate به سمت canary و فلگ حرکت می‌کند.

پایپ‌لاین؛ تکرارپذیر کردن مسیر

پایپ‌لاین استقرار دنبالهٔ خودکار ساخت، تست، بسته‌بندی، استقرار روی تست یا استیج، بررسی بیشتر، و سپس تولید — خودکار یا با تأیید انسان — است. ارزشش تکرارپذیری است: هر تغییر همان مسیر را می‌رود و تست شکست‌خورده به کاربر نمی‌رسد. این ماشین پشت یکپارچه‌سازی و تحویل پیوسته است.

بدون پایپ‌لاین، دیپلوی وابسته به دانش شفاهی یک نفر و چک‌لیست فراموش‌شدنی می‌شود. با پایپ‌لاین، دیپلوی روزمره می‌شود و ترس کم می‌شود؛ شرطش این است که تست‌ها واقعاً سیگنال بدهند نه اینکه فقط سبز تزئینی باشند.

معنای استقرار برای طراح و مدیر محصول

فرض کنید چک‌اوت بازطراحی‌شده آماده است. سؤال دیگر فقط «کی دیپلوی کنیم» نیست؛ «چطور ریلیز کنیم» است. فلگ اجازه می‌دهد ابتدا داخلی، بعد بتا، بعد درصدی از ترافیک، و در صورت افت تبدیل خاموشی سریع. همان ساختار برای آزمون A/B لازم است: نسخهٔ قدیم و جدید در کنار هم برای کاربران قابل مقایسه.

دو موعد برای طراحی مهم است: پنجرهٔ بازبینی در استیج، و لحظهٔ ریلیز که به یادداشت انتشار، changelog درون‌محصول یا اعلام نیاز دارد. طرح وقتی تمام است که منتشر، اندازه‌گیری و برای کاربر توضیح داده شده باشد، نه فقط وقتی در فیگما یا حتی در بیلد استیج نشسته است.

چه چیزهایی خراب می‌شوند و چطور برمی‌گردیم

شکست‌های رایج: تفاوت پیکربندی استیج و تولید، مهاجرت پایگاه که زیر بار قفل می‌شود، وابستگی که روی سرور واقعی فرق می‌کند، یا باگی که فقط روی دستگاه تست‌نشده دیده می‌شود. مانیتورینگ نرخ خطا، تأخیر، و متریک محصول را در دقایق بعد از دیپلوی می‌پاید.

rollback برگرداندن به نسخهٔ سالم قبلی است. hotfix تغییر کوچک بیرون از ریتم عادی برای رفع علت. برای محصول، برنامهٔ برگشت بخشی از برنامهٔ ریلیز است. تغییری که سریع برنمی‌گردد نباید وسیع ریلیز شود؛ canary و فلگ دقیقاً برای محدود کردن تعداد کاربران در معرض باگ‌اند.

فریز استقرار و بسامد انتشار

فریز یعنی در بازهٔ حساس — کمپین فروش، تعطیلات با تیم کم، ممیزی — دیپلوی تولید متوقف می‌شود مگر اضطراری. ریسک قطعی خودساخته پایین می‌آید، اما تغییرات انباشته هنگام برداشتن فریز خود ریسک بَچ می‌سازند. بسامد دیپلوی از چند بار در روز تا چند بار در سال متغیر است؛ پژوهش تحویل نرم‌افزار معمولاً استقرارهای کوچک و مکرر را با شکست کمتر و بازیابی سریع‌تر مرتبط می‌داند.

انتخاب بسامد باید با مدل ریسک کسب‌وکار و نوع محصول — ابری یک‌نسخه‌ای در برابر نصب سازمانی یا استور موبایل — سازگار باشد. موبایل لایهٔ بررسی استور و زمان به‌روزرسانی سمت کاربر را اضافه می‌کند؛ برگشت سخت‌تر از وب ابری است.

نقشه برای تیم‌های محصول ایرانی و بین‌المللی

در سرویس‌های پرداخت و تجارت الکترونیک، دیپلوی نزدیک به پیک ترافیک بدون canary یا مانیتورینگ قوی قمار است. در B2B، پنجرهٔ نگهداری و اطلاع به مشتری بخشی از ریلیز است. هماهنگی پشتیبانی با یادداشت انتشار جلوی تیکت‌های «امروز سایت عوض شده» بدون پاسخ را می‌گیرد.

طراحانی که واژگان دیپلوی، استیج، فلگ و rollback را بلدانند درخواست‌های واقع‌بینانه‌تری می‌دهند: به‌جای «فردا برای همه»، «اول ده درصد با معیار خروج مشخص». این زبان مشترک بین محصول و مهندسی اصطکاک را کم می‌کند.

جمع‌بندی عملیات انتشار

استقرار نرم‌افزار پل بین کد و واقعیت کاربر است. با تفکیک بیلد و ریلیز، محیط‌های مرتب، استراتژی کاهش ریسک، پایپ‌لاین تکرارپذیر، و برنامهٔ برگشت، تیم می‌تواند سریع بیاموزد بدون اینکه هر تغییر به بحران تبدیل شود. این را با مراسم اسکرام اشتباه نگیرید؛ اینجا دربارهٔ ship کردن و زنده نگه داشتن سیستم است.

اگر یک عادت بسازید، هر ریلیز مهم را با مسیر دیپلوی، معیار سلامت، و مالک rollback روی کاغذ یک‌صفحه‌ای شروع کنید. همان صفحه در دقیقهٔ صفر حادثه بیشتر از اسلاید استراتژی ارزش دارد.