عامل شما محیط Production را خراب نکرد. پایپلاین شما این کار را کرد.
عامل شما محیط Production را خراب نکرد. پایپلاین شما این کار را کرد.
بسیاری از تیمها از Agentها برای باز کردن Pull Requestها استفاده میکنند. آنها از CI برای بررسی linting، تستها و buildها استفاده میکنند. سپس، یک job زمانبندیشده کد را از staging به production منتقل میکند. این ساختار در نهایت با شکست مواجه میشود.
مشکل یک Agent مخرب نیست. مشکل یک فرآیند بد است. شما دو سوال متفاوت را در یک دروازه (gate) ادغام کردهاید:
- آیا این از CI عبور کرد؟
- آیا این در حال حاضر برای مشاهده توسط انسان ایمن است؟
اینها یکی نیستند. CI بررسی میکند که آیا کد کار میکند یا خیر. اما بررسی نمیکند که آیا یک ویژگی (feature) برای مشتریان آماده است یا نه.
اگر پایپلاین شما "merged" و "live" را یکسان در نظر میگیرد، مشکل دارید. شما بدون تصمیمگیری، وارد چرخه استقرار مداوم (continuous deployment) شدهاید.
شما باید این دو رویداد را از هم جدا کنید.
میتوانید برای این کار از feature flagها استفاده کنید. feature flagها صرفاً یک مقدار boolean و یک دستور if هستند. برای شروع نیازی به ابزارهای گرانقیمت ندارید. یک مقدار config ساده یا یک متغیر محیطی (environment variable) کافی است.
تنظیمات من از این قوانین پیروی میکند:
- PRها به main merge میشوند، اما main همان چیزی نیست که live میماند.
- یک مرحله release مجزا، main را به یک branch مخصوص production ارتقا میدهد.
- من باید صراحتاً دستور اجرا بدهم. بدون cron job یا تایمر.
- مرحله release منتظر میماند تا build ترافیک را پاسخ دهد.
- یک بررسی خودکار، endpointهای کلیدی را برای تأیید عملکرد سایت هدف قرار میدهد.
- یک انسان بررسی دستی نهایی را روی تغییرات انجام میدهد.
این یک دروازه ایجاد میکند. یک انسان، یک ماشین و یک انسان دیگر، همگی قبل از اینکه کاربر چیزی ببیند، فرصت دارند بگویند "نه".
اگر با این حال باگی به کاربر رسید، باید سریعاً revert کنید. برای این کار، از الگوی expand and contract برای مهاجرتهای پایگاه داده (database migrations) استفاده کنید.
- یک ستون جدید به صورت nullable اضافه کنید.
- دادهها را پر کنید (backfill).
- هم در ستونهای قدیمی و هم در ستونهای جدید بنویسید.
- از ستون جدید بخوانید.
- ستون قدیمی را فقط در یک release بعدی حذف کنید.
اگر این مراحل را نادیده بگیرید، دکمه revert شما بیفایده خواهد بود. اگر یک migration ستونی را که کد قدیمی به آن نیاز دارد حذف کند، نمیتوانید roll back کنید. فقط در وضعیت خراب باقی میمانید.
یک Agent باعث میشود این اشتباهات سریعتر رخ دهند. Agent، اصطکاک دستی را که قبلاً فرآیندهای بد شما را پنهان میکرد، از بین میبرد. انضباطی که نادیده گرفته بودید هرگز اختیاری نبود؛ فقط با توجه یک انسان به یک اشتباه قبل از ساعت ۵ عصر روز جمعه پوشانده میشد.
انسان را از چرخه خارج کنید، آنگاه رعایت انضباط اجباری میشود.
Source: https://dev.to/mattstratton/your-agent-didnt-break-prod-your-pipeline-did-4g9o