Skip to main content

فرآیند Release و Hotfix

این سند، فرآیند استاندارد انتشار نسخه‌های جدید (Release) و رفع مشکلات بحرانی محیط Production (Hotfix) را تعریف می‌کند.

هدف از این فرآیند، اطمینان از انتشار کنترل‌شده، قابل رهگیری و قابل بازگشت تغییرات در محیط Production است.

تمامی Releaseها و Hotfixها باید:

  • قابل رهگیری باشند.
  • دارای ارتباط مشخص با JIRA Issue و تغییرات مربوطه باشند.
  • با فرآیند QA هماهنگ باشند.
  • در صورت بروز مشکل، امکان Rollback داشته باشند.

Release Process​

Release فرآیند انتقال تغییرات تأییدشده از محیط توسعه به Production است.

نسخه Release می‌تواند از Branchهای زیر آماده شود:

  • develop
  • release/<VERSION>

نمونه:

release/1.5.0

استفاده از release Branch در پروژه‌هایی انجام می‌شود که نیاز به مرحله تثبیت (Stabilization) قبل از انتشار نهایی دارند.

الزامات قبل از Merge به main​

قبل از انتقال Release به Branch main، موارد زیر باید انجام و تأیید شده باشند:

Technical Review​

  • تمامی تغییرات باید Technical Review شده باشند.
  • ریسک‌های فنی و اثرات تغییرات بررسی شده باشند.

QA Validation​

  • نسخه نهایی باید روی محیط Stage مستقر شده باشد.
  • تست‌های QA با موفقیت انجام شده باشند.
  • مشکلات شناسایی‌شده باید قبل از Release نهایی برطرف شوند.

Database Migration Review​

در صورت وجود Migration:

  • تغییرات Database باید بررسی شوند.
  • تأثیر Migration روی داده‌های موجود مشخص باشد.
  • در صورت نیاز، برنامه Rollback تعریف شده باشد.

Breaking Change Review​

برای تغییراتی که ممکن است سازگاری نسخه‌های قبلی را تحت تأثیر قرار دهند:

  • Breaking Changeها باید شناسایی شوند.
  • اثرات آن‌ها بررسی شود.
  • هماهنگی‌های لازم قبل از انتشار انجام گیرد.

Product Approval​

در صورت تغییر در رفتار قابل مشاهده کاربر (User Behavior):

  • تأیید Owner محصول باید دریافت شود.

Hotfix Process​

Hotfix برای رفع مشکلات بحرانی در محیط Production استفاده می‌شود و نباید به عنوان مسیر توسعه قابلیت‌های جدید استفاده شود.

Hotfix تنها برای شرایطی مجاز است که یک مشکل فوری نیازمند اصلاح سریع در نسخه Production باشد.

قوانین Hotfix​

  • Branch مربوط به Hotfix باید مستقیماً از main ایجاد شود.
  • نام Branch باید دقیقاً برابر با JIRA Issue Key مربوط به همان مشکل باشد.
  • Scope تغییرات باید فقط محدود به رفع مشکل موجود باشد.
  • افزودن Feature جدید در Hotfix ممنوع است.
  • پس از Merge شدن در main، تغییرات باید در develop نیز Merge شوند تا در نسخه‌های آینده حفظ شوند.

نمونه فرآیند:

main
 │
 ▼
HAMYAR-145
 │
 ▼
main
 │
 └──► Production

 ▼
develop

Rollback Strategy​

برای Releaseهایی که دارای ریسک بالا هستند، مسیر Rollback باید قبل از انتشار مشخص شده باشد.

برنامه Rollback می‌تواند شامل موارد زیر باشد:

Code Rollback​

  • امکان بازگرداندن نسخه کد قبلی بررسی شود.
  • نسخه‌های منتشرشده باید دارای شناسه قابل رهگیری باشند.

Database Rollback​

در صورت وجود Migration:

  • امکان Rollback Migration بررسی شود.
  • در صورت عدم امکان Rollback، روش جایگزین مشخص شود.

Feature Flag​

در صورت وجود Feature Flag:

  • امکان غیرفعال‌سازی سریع قابلیت بررسی شود.
  • رفتار سیستم پس از Disable شدن مشخص باشد.

Data Cleanup​

در صورت نیاز:

  • برنامه پاکسازی یا اصلاح داده‌ها مشخص شود.
  • مسئولیت اجرای آن مشخص باشد.

موارد غیرمجاز​

موارد زیر در فرآیند Release و Hotfix مجاز نیستند:

  • Deploy بدون Tag یا شناسه قابل رهگیری
  • اجرای Migration مخرب بدون Review و بررسی اثرات
  • ایجاد Hotfix بدون Sync کردن تغییرات با develop
  • اعمال تغییرات دستی در Production بدون ثبت و ارتباط با JIRA Issue
  • انتشار Release بدون انجام فرآیند QA

Best Practice تیمی​

برای حفظ کنترل و قابلیت رهگیری Releaseها:

  • هر Release باید دارای Version مشخص باشد.
  • تغییرات منتشرشده باید قابل ارتباط با Commitها و JIRA Issueهای مربوطه باشند.
  • فرآیند Release نباید وابسته به تغییرات دستی خارج از Workflow تعریف‌شده باشد.
  • Hotfixها باید پس از رفع مشکل، به مسیر توسعه اصلی بازگردانده شوند.

جمع‌بندی​

فرآیند Release و Hotfix با هدف ایجاد یک مسیر انتشار امن، قابل کنترل و قابل بازگشت طراحی شده است.

اجرای صحیح این فرآیند باعث می‌شود:

  • ریسک انتشار تغییرات مشکل‌دار در Production کاهش یابد.
  • مشکلات بحرانی سریع‌تر و کنترل‌شده‌تر رفع شوند.
  • تاریخچه تغییرات و نسخه‌های منتشرشده قابل رهگیری باشد.
  • هماهنگی بین تیم‌های Development، QA و Product حفظ شود.

هیچ تغییری نباید بدون مسیر مشخص برای بررسی، انتشار و در صورت نیاز Rollback وارد Production شود.