خط توسعه هم یه سیستم پروداکشنه
خلاصهٔ کاملتر
جری اور تو یه پست کوتاه یه نکتهٔ ساده ولی جاافتاده رو مطرح میکنه: توسعهدهندهها از اول یاد میگیرن که هیچی فوریتر از رفع قطعی پروداکشن نیست، ولی همین حس فوریت رو دربارهٔ خرابی ابزارهای خودشون ندارن. به گفتهٔ نویسنده، برای تیم توسعه خط تولید نرمافزار خودش یه سیستم پروداکشنه.
استدلالش اینه که کار توسعهدهنده تولید ارزش برای شرکته؛ گاهی با ساختن فیچر جدید و گاهی با رفع باگ بحرانی مشتری. ولی وقتی یه چیزی تو خط توسعه خرابه، هیچکدوم از اینها اتفاق نمیافته. اگه کد کامپایل نشه، تیم نرمافزار تولید نمیکنه؛ اگه سرور QA بخوابه، تیم نرمافزارِ سالم تولید نمیکنه. نویسنده میگه هر دوی اینها از دید تیم دقیقاً قطعی پروداکشنه و باید بالاترین اولویت رو بگیره.
به گفتهٔ اون، تو صنعت تولید و همینطور تو مدیریت حادثهٔ IT فرایندهای مفصلی برای کمکردن زمان خواب خط تولید وجود داره، ولی تقریباً همهشون روی سرویسی که به مشتری داده میشه تمرکز دارن، نه روی آدمهایی که همون سرویس رو میسازن و نگه میدارن. همین خلأ باعث میشه خرابی ابزار داخلی همیشه ته صف بمونه.
پیشنهاد عملیش اینه همهٔ اجزای مسیر «مشتری چیزی میخواد» تا «اون چیز تحویل داده شد» رو یهجا فهرست کنی: سیستم ثبت ایشو و درخواست تغییر مثل Jira و GitHub Issues، ابزارهای مستقیم ساخت مثل IDE و Gradle و Maven و مخازن پکیج و دیتابیس لوکال و کانتینر، ابزارهای CI/CD مثل Jenkins و GitHub Actions، تستسوییت قرمز و محیط QA. از نگاه نویسنده هر مرحلهای که جلوی تغییردادن و دیپلوی رو بگیره، جزو همین سیستمه.
نکات کلیدی:
- خرابی بیلد، CI یا محیط QA برای تیم توسعه معادل قطعی پروداکشنه
- تا وقتی خط توسعه خرابه، نه فیچر جدید تحویل میشه نه باگ بحرانی مشتری
- فرایندهای رایج مدیریت حادثه بیشتر سرویس مشتری رو پوشش میدن، نه ابزار خود تیم
- کل مسیر از ثبت درخواست تا دیپلوی رو باید یه سیستم واحد دید
- هر چیزی که جلوی تغییر و دیپلوی رو بگیره، باید اولویت اول باشه
