مدیریت انتشار نسخه
معیار سلامت فرایند انتشار در یک جمله: آیا انتشار نسخه یک رویداد است؟
اگر شب انتشار همه بیدارند، اگر روزش را از قبل در تقویم علامت میزنند، اگر بعدش نفس راحتی کشیده میشود — فرایند شما مشکل دارد. نه چون آدمها بد کار میکنند، بلکه چون هرچه انتشار نادرتر و بزرگتر باشد، پرریسکتر است، و هرچه پرریسکتر باشد کمتر انجامش میدهید. این حلقه خودش را تشدید میکند.
هدف، انتشار کسلکننده است.
چرا انتشار بزرگ خطرناکتر است
ساده است: اگر نسخهای شامل سه تغییر باشد و چیزی بشکند، سه مظنون دارید. اگر شامل سی تغییر باشد، سی مظنون — و کشف اینکه کدام بوده، ساعتها طول میکشد، معمولاً هم در بدترین زمان ممکن.
پس انتشار مکرر و کوچک، ذاتاً کمریسکتر از انتشار نادر و بزرگ است، حتی اگر حس برعکس بدهد. حس برعکس از این میآید که هر انتشار هزینهٔ ثابتی دارد؛ جواب این است که آن هزینهٔ ثابت را با خودکارسازی پایین بیاورید، نه اینکه تعداد را کم کنید.
شمارهگذاری نسخه
قرارداد رایج سه بخش دارد و ارزشش در این است که به مصرفکننده اطلاعات میدهد:
نسخهٔ اصلی وقتی بالا میرود که چیزی شکسته باشد — رفتاری که قبلاً بود دیگر نیست. مصرفکننده باید کاری بکند.
نسخهٔ فرعی برای قابلیت جدیدِ سازگار با گذشته.
نسخهٔ اصلاحی برای رفع باگ.
این برای هر چیزی که مصرفکنندهٔ بیرونی دارد — رابط برنامهنویسی، کتابخانه، اپلیکیشن موبایل — جدی است. برای سامانهٔ داخلی که فقط خودتان مصرفش میکنید، تاریخ بهعلاوهٔ شمارهٔ ترتیب کافی است و تظاهر به بیشتر، تشریفات است.
آنچه در هر دو حالت لازم است: هر نسخه باید به کامیت مشخصی قابل ردیابی باشد و سامانهٔ در حال اجرا باید بتواند بگوید چه نسخهای است. صفحهٔ سلامتی که نسخه و تاریخ ساخت را نشان دهد، در اولین بررسی مشکل به کارتان میآید.
یادداشت انتشار
برای هر نسخه، سه فهرست: چه چیزی اضافه شد، چه چیزی اصلاح شد، چه چیزی تغییر کرد که ممکن است اذیت کند.
مورد سوم مهمترین است و معمولاً نوشته نمیشود. کاربری که فردا صبح دکمه را سر جایش پیدا نمیکند، اگر از قبل خبر داشته باشد ناراضی نمیشود؛ اگر نداشته باشد، تیکت میزند.
و برای مخاطب بنویسید، نه برای خودتان. «اصلاح در سرویس تسویه» به کاربر چیزی نمیگوید. «مشکل نمایش مانده حساب در گزارش ماهانه رفع شد» میگوید.
پرچم قابلیت
ابزاری که بیشترین تفاوت را در فرایند انتشار میسازد و کمترین استفاده را دارد.
ایدهاش این است که کد را منتشر کنید ولی قابلیت را خاموش نگه دارید. سوئیچی که بدون انتشار جدید روشن و خاموش میشود.
سه چیز را ممکن میکند:
جدا کردن انتشار از عرضه. کد ماهها روی محیط اصلی باشد و روزی که کسبوکار آماده است روشن شود. دیگر لازم نیست تیم فنی منتظر تقویم بازاریابی بماند.
خاموشی سریع. اگر قابلیت جدید مشکل دارد، خاموشش کنید. ثانیهها بهجای دقیقههای بازگشت نسخه.
عرضهٔ تدریجی. اول برای کارکنان داخلی، بعد ده درصد کاربران، بعد همه.
هزینهاش هم واقعی است: هر پرچم یعنی دو مسیر کد که هر دو باید کار کنند. پرچمی که پاک نشود به بدهی تبدیل میشود. قاعدهای که در پروژههایمان داریم: هر پرچم تاریخ انقضا دارد و بعد از تثبیت قابلیت، پرچم و مسیر قدیمی حذف میشوند.
بازگشت واقعی، نه روی کاغذ
تقریباً همهٔ تیمها میگویند برنامهٔ بازگشت دارند. تقریباً هیچکدام امتحانش نکردهاند.
سه سؤال که وضعیت واقعی را روشن میکند:
بازگشت چقدر طول میکشد؟ اگر جواب «حدود یک ساعت» است، در قطعی سرویس عملاً گزینه نیست.
آخرین بار کی امتحانش کردید؟ برنامهای که اجرا نشده، فرضیه است.
با مهاجرت پایگاه داده چه میکنید؟ اینجاست که بیشتر برنامههای بازگشت میشکنند. کد برمیگردد و اسکیما نه. اگر ستونی حذف یا تغییر نوع داده شده باشد، نسخهٔ قبلی کد اصلاً بالا نمیآید.
راه درست همان است که در بخش CI/CD گفتیم: تغییرات اسکیما را جوری بدهید که با نسخهٔ قبلی کد هم سازگار باشند — افزودن در یک انتشار، استفاده در بعدی، حذف قدیمی در سومی. کند به نظر میرسد و تنها روشی است که بازگشت را واقعی نگه میدارد.
پنجرهٔ انتشار
بحث قدیمی: جمعه شب منتشر کنیم یا نه؟
جواب ما: در ساعتی منتشر کنید که آدمهای لازم بیدار و در دسترساند. این معمولاً یعنی صبح روز کاری، نه نیمهشب پنجشنبه.
استدلال «شب منتشر کنیم که کاربر کمتری آسیب ببیند» فقط وقتی درست است که بازگشت سریع و آزموده داشته باشید. وگرنه فقط تضمین کردهاید که مشکل را خستهترین آدمها، با کمترین کمک در دسترس، حل کنند.
در سامانههای سازمانی داخلی معمولاً پنجرهٔ طبیعی وجود دارد — پیش از شروع ساعت کاری. از آن استفاده کنید و بندش را در قرارداد پشتیبانی بیاورید تا انتظار طرفین یکی باشد.
و انتشار در روزهای حساس ممنوع. پایان دورههای مالی، روزهای اوج فروش، آخرین روز مهلت اظهارنامه. فهرست این روزها را با کسبوکار بنویسید و در تقویم بگذارید؛ تیم فنی خودش نمیداند فردا آخرین مهلت چیست.
اپلیکیشن موبایل، حالت خاص
انتشار موبایل با وب فرق اساسی دارد: نمیتوانید همه را به نسخهٔ جدید ببرید.
نتیجهاش این است که سرویس شما باید مدتها با نسخههای قدیمی اپ سازگار بماند. دو تصمیمی که باید از ابتدا گرفته شوند:
نسخهبندی رابط برنامهنویسی، تا تغییر سرویس، اپهای قدیمی را نشکند.
اجبار بهروزرسانی، برای وقتی که واقعاً چارهای نیست — با پیام روشن و امکان ادامه در حالت محدود، نه دیوار بسته.
و در بازار داخلی، توزیع از چند کاناله بودن رنج میبرد: کافهبازار، مایکت، سایت خودتان. هر کدام تأخیر بازبینی خودش را دارد، پس همزمانی انتشار در کانالها را نباید فرض کنید. اگر سرویس شما فرض کند همه یک نسخه دارند، در همان روز اول میشکند.
نشانههای اینکه فرایند سالم است
- انتشار در ساعات کاری انجام میشود و کسی نگران نیست.
- هر کسی در تیم میتواند منتشر کند، نه فقط یک نفر.
- بازگشت در چند دقیقه ممکن و امتحانشده است.
- بین آمادهشدن کد و رسیدنش به کاربر، روزها فاصله نیست.
اگر این چهار را دارید، فرایند انتشارتان از اکثر سازمانها بهتر است — و مهمتر، تیم شما دیگر از تغییر نمیترسد.