مدیریت Release در پروژه‌های بانکی: Develop، Staging و Production بدون استرس

در پروژه‌های بانکی و سازمانی، مثل کیف پول‌ها، سامانه‌های پرداخت یا سامانه‌های تأمین اجتماعی، انتشار نسخه‌ی جدید فقط یک git push نیست. کارفرما تست پذیرش می‌خواهد، واحد امنیت گزارش می‌خواهد و در نهایت کسی باید امضا کند که «این نسخه برای Production آماده است». اگر فرایند Release روشن نباشد، هر انتشار به یک شب پراسترس تبدیل می‌شود.

در این مقاله چارچوبی را توضیح می‌دهم که در پروژه‌هایی با محیط‌های Develop، Staging و Production به کار برده‌ام.

هر محیط برای چیست؟

اصل اول: یک‌بار Build، چندبار Deploy

بزرگ‌ترین اشتباهی که دیده‌ام، Build جداگانه برای هر محیط است. اگر برای Production دوباره Build کنید، ممکن است نسخه‌ی یک وابستگی یا Base Image عوض شده باشد و چیزی که در Staging تأیید شده، با چیزی که به Production می‌رود یکی نباشد.

commit a1b2c3d
   │
   ▼
 build ──▶ harbor.example.ir/bank/api:1.9.0  (sha256:7f3e…)
                │
     ┌──────────┼──────────────┐
     ▼          ▼              ▼
  Develop ──▶ Staging ──▶ Production     same digest everywhere

تفاوت محیط‌ها فقط در پیکربندی است (فایل‌های Values در Helm، ConfigMap و Secretها)، نه در Image.

اصل دوم: نسخه‌گذاری معنایی

از Semantic Versioning (MAJOR.MINOR.PATCH) استفاده کنید:

• 1.9.0 → 1.9.1: رفع باگ، بدون تغییر رفتار
• 1.9.0 → 1.10.0: قابلیت جدید، سازگار با قبل
• 1.9.0 → 2.0.0: تغییر ناسازگار، مثل تغییر API یا قرارداد با سامانه‌های دیگر

Tag گیت، Tag Image، نسخه‌ی Helm Chart و شماره‌ای که در نامه‌ی رسمی به کارفرما نوشته می‌شود، همه یک عدد باشند. ابزارهایی مثل semantic-release یا release-please می‌توانند نسخه را از پیام Commitها (Conventional Commits) استخراج و Changelog را خودکار بسازند.

اصل سوم: استراتژی Branch ساده

برای بیشتر تیم‌ها، Trunk-based همراه با Release Branch بهترین تعادل را دارد:

main ──●──●──●──●──●──●──●──▶        (always deployable, auto → Develop)
              \           \
   release/1.9 ●──●(fix)    release/1.10 ●──▶
               │                         │
            tag v1.9.0 → Staging → Production   tag v1.10.0

• همه‌ی کارها به main Merge می‌شود و Develop همیشه آخرین نسخه را دارد.
• برای هر انتشار یک release/x.y جدا می‌شود. رفع باگ‌های Staging روی همین Branch انجام و به main هم Cherry-pick می‌شود.
• Tag روی Release Branch، Pipeline استقرار Staging و Production را فعال می‌کند.

اصل چهارم: Promotion با تأیید و ردپا

در GitLab، استقرار Staging و Production را Manual و محیط Production را Protected کنید تا فقط افراد مشخص بتوانند Deploy کنند. در نسخه‌های Premium، قابلیت Deployment Approvals امکان تأیید چندنفره (مثلاً مدیر فنی و نماینده‌ی کارفرما) را هم می‌دهد.

deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://api.example.ir
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
      when: manual
  resource_group: production      # never two production deploys at the same time
  script:
    - ./deploy.sh production "$CI_COMMIT_TAG"

resource_group تضمین می‌کند حتی اگر دو نفر هم‌زمان دکمه‌ی Deploy را بزنند، استقرارها پشت سر هم اجرا شوند و با هم تداخل نکنند.

صفحه‌ی Environments در GitLab دقیقاً نشان می‌دهد چه نسخه‌ای، چه زمانی و توسط چه کسی روی هر محیط مستقر شده است. این همان ردپایی است که واحد Audit و بازرسی در پروژه‌های بانکی می‌خواهد.

اصل پنجم: دیتابیس، بخش پرریسک

بیشتر Rollbackهای ناموفقی که دیده‌ام، به دیتابیس برمی‌گشتند. چند قانون:

1. Migration جدا از برنامه اجرا شود؛ مثلاً یک Job در Kubernetes قبل از Deploy (یا یک Sync Wave در ArgoCD).
2. Migrationها سازگار با نسخه‌ی قبل باشند (الگوی Expand/Contract). حذف ستون یا تغییر نام، همیشه در Release بعدی.
3. قبل از هر Release در Production، Backup گرفته و زمان بازگردانی‌اش مشخص باشد.
4. Migration را دقیقاً یک‌بار روی Staging با داده‌ای به حجم واقعی تست کنید؛ Migrationی که روی ۱۰۰ رکورد یک ثانیه طول می‌کشد، روی ۵۰ میلیون رکورد ممکن است یک ساعت جدول را قفل کند.

چک‌لیست Release

قبل از انتشار

• Staging توسط کارفرما تأیید و صورت‌جلسه شده
• گزارش اسکن امنیتی (SonarQube، Trivy، ZAP) بدون مورد Critical باز
• Changelog و یادداشت انتشار آماده
• Backup دیتابیس گرفته شده و برنامه‌ی Rollback نوشته شده
• زمان انتشار به تیم پشتیبانی و سامانه‌های وابسته اطلاع داده شده

هنگام انتشار

• Migration اجرا و بررسی شده
• استقرار با استراتژی Rolling یا Blue/Green انجام شده
• Smoke Test روی مسیرهای حیاتی (ورود، پرداخت، گزارش) موفق بوده

بعد از انتشار

• داشبوردهای Grafana حداقل ۳۰ دقیقه پایش شده: درصد خطا، زمان پاسخ و تراکنش‌ها
• Tag و Release Note در GitLab ثبت شده

جمع‌بندی

Release Management خوب، انتشار را از یک رویداد پرخطر به یک کار تکراری و کسل‌کننده تبدیل می‌کند و هدف دقیقاً همین است. با تعریف روشن محیط‌ها، یک Image ثابت برای همه، نسخه‌گذاری منظم، Promotion قابل Audit و احترام به دیتابیس، می‌توانید با خیال راحت و حتی هفتگی منتشر کنید.