بهترین معماری با استقرارِ ترسناک بیارزش است. هدف: انتشارِ کوچک، مکرر، خودکار و قابلبرگشت — طوری که دیپلوی جمعه عصر هم ترس نداشته باشد.
Container — Docker
اپ + وابستگیها در بستهای قابل حمل؛ «روی سیستم من کار میکرد» را حذف میکند.
Kubernetes
ارکستراتور: تعداد نسخهها، جای اجرا، health check، ریاستارت، auto-scale — declarative: تو «وضعیت مطلوب» را میگویی، او نگه میدارد.
CI/CD
هر commit: تست و build خودکار (CI) و استقرار خودکار/نیمهخودکار (CD). خط لوله = دروازه کیفیت.
IaC
زیرساخت بهصورت کد (Terraform): بازتولیدپذیر، قابل review، بدون «سرور دستساز مقدس».
استراتژیهای انتشار
| استراتژی | روش | نکته |
|---|---|---|
| Rolling | تعویض تدریجی نسخهها | پیشفرض K8s؛ دو نسخه موقتاً همزیستاند |
| Blue-Green | محیط جدید کامل بالا، سوییچ یکجا | برگشتِ فوری؛ هزینه دوبرابر لحظهای |
| Canary | اول ۱٪ ترافیک به نسخه جدید، پایش، بعد رشد | کشف مشکل با کمترین آسیب |
| Feature Flag | قابلیت در کد هست ولی با سوییچ روشن میشود | جداکردن «دیپلوی» از «انتشار»؛ خاموشی فوری بدون دیپلوی |
- قانون همزیستی: در Rolling/Canary دو نسخه همزمان زندهاند → تغییرات DB باید backward-compatible باشند (اول ستون اضافه کن، بعد کد، بعد حذفِ قدیمی).
- Rollback باید یک دکمه باشد، نه یک پروژه.
- محیط staging شبیهِ production + دیتای مصنوعی؛ تستِ فقط-لوکال دروغ میگوید.
به زبان ساده
انتشار امن یعنی تغییر کوچک را اول روی بخش کمی از کاربران امتحان کنیم و راه برگشت داشته باشیم.
مثال واقعی
نسخه جدید را ابتدا برای ۱٪ کاربران میفرستیم؛ اگر خطا یا p99 بدتر شد، canary را خودکار برمیگردانیم.