معروف ترین استراتژی‌های برنچینگ در Git

اصول غیرقابل مذاکره در Trunk-Based

1. یک شاخه اصلی (main) منبع حقیقت است.

2. تغییرات کوچک و پرتکرار به main می‌رسند.

3. برنچ‌ها اگر وجود دارند خیلی کوتاه‌عمر هستند (ساعت‌ها تا حداکثر ۱–۲ روز).

4. «کار ناتمام» را با Feature Flag / Toggle و Backward Compatibility هندل می‌کنیم، نه با برنچ طولانی.

5. کیفیت با گیت‌های اتومات + کدریویو سبک حفظ می‌شود، نه با فازهای طولانی فریز.

1) ساختار ریپو و برنچینگ استاندارد

شاخه‌ها

• main (یا trunk): تنها شاخه دائمی

• short-lived branches (اختیاری اما رایج):
  feature/<ticket> یا fix/<ticket> با عمر کوتاه

• release branch (فقط در صورت نیاز، موقتی):
  وقتی production از یک commit قدیمی‌تر است یا نیاز به patch سریع روی نسخه منتشرشده دارید.
  

قانون طلایی برنچ‌ها

• فیچر برنچ طولانی نداریم.
  

• اگر کاری بزرگ است: به چند PR کوچک + feature flag بشکن.

2) از صفر تا صد جریان توسعه (Development Flow)

مرحله 1: برنامه‌ریزی و شکستن کار

چه چیزهایی اینجا هندل می‌شود؟

• شکستن فیچر بزرگ به “vertical slices” (قابل merge شدن)

• تعریف flagها

• تعریف migration plan دیتابیس (اگر هست)

• تعریف معیار Done و تست‌ها

خروجی استاندارد:

• هر slice یک Ticket + یک PR کوچک
  

مرحله 2: پیاده‌سازی روی برنچ کوتاه‌عمر یا مستقیم روی main

استاندارد رایج:

• تیم‌های کوچک: مستقیم روی main با commits کوچک + CI

• تیم‌های متوسط/بزرگ: برنچ کوتاه + PR

فیچرهای نیمه‌کاره چطور merge می‌شن؟

با Feature Flag:

• flag پیش‌فرض OFF

• مسیرهای جدید پشت flag
  UI/endpoint جدید hidden یا limited

مرحله 3: تست‌ها در چه مرحله‌ای و چگونه؟

بهترین استاندارد در trunk-based اینه که «تست‌ها نزدیک به کد» و اتومات باشند:

A) قبل از PR (لوکال)

• unit tests

• lint/format

• type check (اگر دارید)

• اجرای quick smoke

B) در CI روی PR

گیت‌های لازم (Minimum Standard):

• Build ✅

• Unit tests ✅

• Lint/Static analysis ✅

• Security basic: dependency scan / SAST سبک ✅

• حداقل یک لایه integration/contract سریع ✅

• Coverage gate (اختیاری ولی مفید) ✅

C) بعد از merge روی main

• تست‌های سنگین‌تر (integration گسترده‌تر)

• e2e/smoke روی محیط staging

• performance sanity (اگر مهمه)

نکته: e2e را کم اما مؤثر نگه دارید (شکننده نشه).

مرحله 4: کدریویو استاندارد در Trunk-Based

کدریویو هست، ولی سبک، سریع، با SLA.

قواعد پیشنهادی:

• PR کوچک (ترجیحاً < ۲۰۰–۴۰۰ خط تغییر)

• ۱ Reviewer کافی (برای تغییرات معمول)

• ۲ Reviewer برای تغییرات حساس (Security/Payments/Core)

Reviewer روی این‌ها تمرکز کند:

• correctness & edge cases

• backward compatibility

• تست کافی

• خوانایی/maintainability

• migration safety

• flag درست

Anti-pattern:

• PR بزرگ و چندروزه → عملاً می‌شه mini-waterfall

3) ادغام (Merge) و قوانین محافظت از main

Branch Protection استاندارد

• merge فقط با CI green

• حداقل ۱ approval

• no direct push (برای اکثر تیم‌ها)

• squash merge یا rebase merge (سلیقه‌ای، ولی تاریخچه تمیز مهمه)

• commit message با ticket/semantic (مفید برای versioning)

4) CI/CD استاندارد: از merge تا release

مرحله 1: بعد از merge

• build artifact (docker image / package)

• ثبت artifact با یک شناسه:

git_sha
build number

deploy خودکار به staging

مرحله 2: QA روی staging

استاندارد:

• smoke + regression کوتاه (روی flows حیاتی)

• exploratory روی تغییرات جدید

• اگر feature پشت flag است:
  
  

  flag را در staging روشن می‌کنند یا برای user گروهی باز می‌کنند
  
  

مرحله 3: Production release

دو مدل استاندارد:

مدل A) Continuous Deployment (پیشرفته)

• هر merge با گیت‌ها → مستقیم تا prod (با canary/flags)

مدل B) Continuous Delivery (رایج‌تر)

• هر merge آماده انتشار است

• انتشار با “promote” کردن همان artifact انجام می‌شود

• معمولاً روزانه/هفتگی “release train”

5) Tag گذاری و Versioning استاندارد

تگ‌ها چرا؟

برای اینکه بگیم کد دقیقا چه نسخه‌ای روی prod رفته.

استاندارد معمول:

• روی همان commit که deploy می‌شود:

  • vMAJOR.MINOR.PATCH (SemVer)

  • یا release-2026.02.23-1 (Calendar Versioning)
    
    

    قانون مهم:

• تگ روی main است (یا روی release branch موقت)

• artifact باید قابل trace باشد:

 tag -> commit -> build -> deploy

Release Notes

• اتومات از commit messages/PR titles

• یا از labels (feature/fix/breaking)

6) Hotfix / Bugfix در trunk-based

اگر باگ در main هم هست

• PR کوتاه → merge main → deploy

اگر prod روی commit قدیمی است

• ایجاد release/<version> موقت از همان tag

• patch روی آن

• deploy patch

• بعد همان patch را به main هم merge/cherry-pick می‌کنیم
  

7) Multi-tenant و نسخه‌ها (Versioning در مولتی‌تننت)

این بخش خیلی مهمه چون “نسخه برای همه” همیشه درست نیست.

سناریوی استاندارد 1: یک کدbase، رفتار متفاوت per-tenant

راه استاندارد: Feature Flags / Tenant Config

• flag می‌تواند:
  
  

  • global
    
    

  • per-tenant
    
    

  • درصدی (rollout)
    
    

  • گروهی (beta users)
    
    

مزیت: یک نسخه کد، rollout کنترل‌شده
نیاز: سیستم flag/config قوی + observability

سناریوی استاندارد 2: tenantهای خاص روی نسخه قدیمی می‌مانند

این معمولاً ضد الگوی trunk-based است، اما اگر مجبورید:

• به جای نگه داشتن شاخه‌های طولانی، بهتر:
  

  • یک “compat layer” و feature flags داشته باشید
    
    

    - و نهایتاً tenantها را migrate کنید
    
    

• اگر واقعاً نسخه‌های جدا لازم است:

  • release branches طولانی می‌شود (نزدیک به GitFlow) و هزینه نگهداشت بالا می‌رود

جمع‌بندی استاندارد:
در trunk-based، multi-version per tenant را با toggle/config حل می‌کنند، نه branch.

8) Database Migrations و Backward Compatibility

این جاییه که خیلی‌ها زمین می‌خورند.

استاندارد مهاجرت امن (Expand/Contract)

1. Expand: ستون/جدول جدید اضافه کن (بدون شکستن قدیمی)

2. اپلیکیشن همزمان از هر دو پشتیبانی کند

3. داده‌ها backfill شوند (job)

4. وقتی مطمئن شدی همه جا migrated:

5. Contract: حذف ساختار قدیمی

قانون طلایی:

• هر deploy باید با نسخه قبلی هم‌زیست باشد (rolling deploy safe)
  

9) Code Freeze در trunk-based

ترانک‌بیسد ذاتاً ضد “فریز طولانی” است، ولی در عمل گاهی لازم می‌شود.

جایگزین استاندارد فریز

• به جای فریز: Release cut + flags
  

  • main ادامه پیدا می‌کند
    
    

  • برای release فقط artifact مشخص promote می‌شود
    
    

• اگر مجبور به فریز هستید:
  

  • فریز خیلی کوتاه (ساعت‌ها) برای release window
    
    

    -فقط برای تغییرات risky
    
    

  • بقیه merge می‌شوند ولی پشت flag OFF می‌مانند
    

بهترین استاندارد:

• “Freeze code” را تبدیل کنید به “Freeze flags” (یعنی قابلیت‌ها خاموش تا زمان آماده شدن)
  
  

10) مدیریت ریسک انتشار: Canary / Blue-Green / Rollback

استانداردهای کنترل ریسک

• Canary: درصد کمی از ترافیک tenantها/کاربرها

• Blue-Green: دو محیط prod و سوئیچ

• Rollback:
  

  rollback به نسخه قبل باید سریع باشد

  • اما ترجیح trunk-based: roll forward (fix سریع)

  • برای DB: rollback سخت است، برای همین expand/contract حیاتی است

11) Observability و SRE gates

چیزهایی که خیلی‌ها در فرآیند نمی‌گویند ولی باید باشد:

• logging ساختاریافته با correlation id

• metrics (latency, error rate, saturation)

• tracing (اگر microservices)

• alerts روی SLOها

• health checks (readiness/liveness)

• automated smoke در prod بعد از deploy

12) امنیت و Compliance در خط CI/CD

حداقل استاندارد:

• dependency scanning (CVEs)

• secret scanning

• SAST سبک

• برای تغییرات حساس: threat modeling سبک + manual review

13) استاندارد تعریف “Done”

یک تغییر فقط وقتی Done است که:

• merge شده

• تحت flag/باگیت‌ها امن است

• تست‌ها پاس است

• روی staging دیده شده (حداقل smoke)

• release note قابل تولید است

• observability برایش وجود دارد (حداقل log/metric)

14) چک‌لیست نهایی: چیزهایی که باید حتماً در نظر بگیرید

اگر بخوام “همه موارد مهم” را یکجا لیست کنم:

حتماً داشته باشید

• Feature Flags (global + per-tenant + gradual rollout)

• CI gates قبل از merge

• branch protection

• artifact immutability + promote

• tagging/release notes

• expand/contract برای DB

• canary/blue-green یا حداقل rollback plan

• monitoring + alerting

• تعریف SLA برای code review

• محدودیت اندازه PR + policy برنچ کوتاه

معمولاً فراموش می‌شود

• قرارداد API/contract tests بین سرویس‌ها

• مدیریت schema version و backward compatibility

• مدیریت config per tenant

• تست داده‌های واقعی‌نما (seed/masking)

• چرخه خاموش کردن flagها (flag debt)

• runbook برای incident + hotfix مسیر سریع

یک نمونه “فرآیند استاندارد” خیلی خلاصه (قابل اجرا)

1. Ticket → PR کوچک

2. لوکال: unit+lint

3. PR: CI gates + 1 review

4. merge به main

5. CI: build artifact + deploy staging

6. QA: smoke/regression (flags)

7. promote به prod (canary اگر شد)

8. tag نسخه + release notes

9. monitor + rollback/roll-forward plan

10. پاکسازی: حذف flagهای قدیمی، contract migrations
    0) اصول GitFlow

• دو شاخه دائمی و اصلی داریم:
  

  • main (یا master): فقط کدِ Production-ready / نسخه‌های منتشرشده

  • develop: خط اصلی توسعه (Integration branch)

• توسعه روزمره روی develop جمع می‌شود.

• انتشار به prod از طریق release/*

• هات‌فیکس روی prod از طریق hotfix/*

• فیچرها روی feature/* انجام می‌شوند.

1) ساختار شاخه‌ها و نقش هرکدام

شاخه‌های دائمی

• main: هر commit (یا هر tag) نماینده یک ریلیز واقعی است.

• develop: جدیدترین وضعیت توسعه و ادغام فیچرها.

شاخه‌های موقت

• feature/<name>: برای پیاده‌سازی فیچرها

• release/<version>: آماده‌سازی انتشار (freeze نسبی)

• hotfix/<version>: رفع مشکل فوری روی production

2) جریان کامل توسعه (Development Flow)

مرحله 1: شروع فیچر

چه می‌شود؟

• از develop برنچ می‌زنید:
  
  

  • feature/ABC-123-user-profile
    
    

اینجا چه چیزهایی هندل می‌شود؟

• کارهای بزرگ معمولاً روی همین feature branch انجام می‌شوند (برخلاف trunk-based که خرد می‌کردیم)

• Feature flag هم می‌تواند باشد، ولی GitFlow بدون flag هم کار می‌کند چون فیچر جداست.
  

مرحله 2: تست‌ها در طول توسعه

A) لوکال (توسعه‌دهنده)

• unit / lint / type check
  

B) CI روی feature branch / PR به develop

استاندارد خوب:

• build

• unit

• lint

• security scan پایه

• integration/contract سبک

در GitFlow معمولاً CI روی PR به develop خیلی مهم است چون develop محل ادغام چند فیچر است و سریع خراب می‌شود.

مرحله 3: کدریویو و Merge به develop

استاندارد GitFlow:

• feature → PR به develop

• code review (۱ یا ۲ نفر)

• merge وقتی CI سبز است

نکته کلیدی GitFlow:

• اختلاف و conflict زیادتر از trunk-based می‌شود چون feature branch ها ممکن است طولانی باشند.
  
  

3) Release آماده‌سازی (Release Branch + Code Freeze)

اینجا GitFlow خیلی «رسماً» وارد فاز انتشار می‌شود.

مرحله 4: ایجاد Release Branch

وقتی تصمیم گرفتید نسخه منتشر کنید:

• از develop برنچ می‌زنید:
  
  

  • release/1.8.0
    
    

از اینجا به بعد چه اتفاقی می‌افتد؟

• Feature Freeze: فیچر جدید به این release branch اضافه نمی‌شود.

• فقط این‌ها مجاز است:

  • باگ‌فیکس
    
    

  • تغییرات نسخه‌دهی
    
    

  • مستندات release
    
    

  • آماده‌سازی پکیج/کانفیگ
    
    

تست QA اینجا کجاست؟

استاندارد GitFlow:

• QA اصلی و سنگین معمولاً روی release branch انجام می‌شود:

  • regression کامل‌تر
    
    

  • e2e گسترده
    
    

  • تست‌های عملکردی/سازگاری
    
    

  • UAT
    
    

4) Tag گذاری و نسخه‌دهی

مرحله 5: وقتی release آماده شد

• release/1.8.0 به main merge می‌شود

• روی main tag می‌زنیم:
  
  

  • v1.8.0
    
    

سپس:

• همان release/1.8.0 به develop هم merge می‌شود
  (تا باگ‌فیکس‌های مرحله release دوباره به خط توسعه برگردد)

✅ این نقطه، “لحظه رسمی انتشار” در GitFlow است

5) Hotfix / Bugfix در GitFlow

سناریو: باگ در Production

1. از main برنچ می‌زنید:

   • hotfix/1.8.1

2. fix انجام می‌شود + تست

3. merge به main

4. tag:

   • v1.8.1
     
     

5. merge به develop هم انجام می‌شود (خیلی مهم!)

چرا merge به develop؟
برای اینکه fix فقط روی prod نماند و در توسعه آینده گم نشود.

6) Multi-tenant و نسخه‌های مختلف در GitFlow

GitFlow ذاتاً کمک می‌کند نسخه‌ها جدا نگه داشته شوند، ولی هزینه دارد.

حالت رایج 1: همه tenantها یک نسخه

• ساده: release branch → main → همه tenantها
  
  

حالت رایج 2: tenantهای مختلف روی نسخه‌های مختلف

در GitFlow این ساده‌تر از trunk-based است، چون:

• می‌توانید release branch های جدا برای نسخه‌های مختلف نگه دارید

• یا maintenance branch برای نسخه‌های قدیمی بسازید (مثلاً support/1.7)

ولی هزینه‌ها:

• backport bugfix ها به چند شاخه

• انفجار تست و QA

• مدیریت همگرایی سخت‌تر

7) Database migrations در GitFlow

همان قواعد فنی پابرجاست، ولی زمان‌بندی فرق دارد:

• تغییرات schema بزرگ معمولاً در feature branch شروع می‌شود

• اما “قفل” و هماهنگی دیتابیس اغلب در release branch چک می‌شود

• بهترین استاندارد همچنان:
  
  

  • expand/contract
    
    

  • backward compatible migrations
    
    

GitFlow باعث می‌شود migrationها ممکن است دیرتر “در کنار هم” تست شوند (چون feature branch ها جدا هستند).

8) Code Freeze در GitFlow استاندارد است

برخلاف trunk-based که سعی می‌کنیم حذفش کنیم، در GitFlow:

• فریز عملاً بخشی از فرایند است:
  
  

  • وقتی release branch ساخته شد، فیچر جدید وارد آن نمی‌شود
    
    

• طول فریز بستگی به QA/UAT دارد (ممکن است چند روز تا چند هفته)

9) Rollback و کنترل ریسک انتشار

در GitFlow معمولاً:

• ریلیزها کمتر و بزرگ‌ترند → ریسک هر ریلیز بالاتر
  استانداردهای مفید:

• deploy مرحله‌ای (staging → prod)

• canary/blue-green (اختیاری ولی خیلی توصیه می‌شود)

• rollback به tag قبلی در main
  

10) Observability / امنیت در GitFlow

همان ابزارها باید باشد، اما گیت‌ها معمولاً در چند نقطه اعمال می‌شود:

• PR به develop

• PR به release/*

• merge به main (آخرین گیت)

11) خلاصه مرحله‌ای GitFlow (End-to-End)

1. feature/* از develop

2. توسعه + تست + CI

3. PR → merge به develop

4. زمان ریلیز: release/* از develop

5. QA سنگین روی release/* + باگ‌فیکس فقط همینجا

6. merge release/* → main + tag نسخه

7. merge release/* → develop

8. hotfix: hotfix/* از main → merge به main + tag → merge به develop

12) مواردی که باید در GitFlow حواستان باشد (نکات واقعیِ پروژه‌ای)

چیزهایی که GitFlow را سخت می‌کند:

• feature branch های طولانی → conflict زیاد

• ادغام دیرهنگام → باگ‌ها دیر دیده می‌شوند

• QA bottleneck روی release branch

• backport های متعدد (اگر چند نسخه/tenant دارید)

• drift بین develop و main اگر mergeها دقیق انجام نشود

نکته مهم: GitHub Flow خیلی نزدیک به Trunk-Based است، با این تفاوت که «همه چیز از طریق PR به main» انجام می‌شود و معمولاً یک develop دائمی نداریم.

0) اصول GitHub Flow

1. یک شاخه اصلی: main

2. main همیشه deployable است (قابل انتشار)

3. هر کار (feature/bugfix/hotfix) روی یک branch کوتاه‌عمر انجام می‌شود

4. merge فقط از طریق Pull Request + گیت‌های CI + review

5. بعد از merge: deploy (یا اتومات یا با دکمه Promote)
   

1) ساختار شاخه‌ها

شاخه دائمی

• main

شاخه‌های موقت

• feature/<ticket>-<slug>

• fix/<ticket>-<slug>

• chore/<slug>

• (اختیاری) release/<version> فقط اگر واقعاً لازم شد (در GitHub Flow اصولاً کمتر استفاده می‌شود)

قانون: برنچ‌ها کوتاه، PR کوچک، merge سریع.

2) جریان کامل توسعه (End-to-End)

مرحله 1: شروع کار

1. از main برنچ می‌زنید:

   • feature/ABC-123-checkout-discounts
     

2. تغییرات را کوچک نگه می‌دارید (slice)

اینجا چی باید هندل بشه؟

• اگر فیچر بزرگ است: از همین اول Feature Flag تعریف کنید

• اگر DB دارد: plan برای migration امن (expand/contract)

مرحله 2: توسعه و کار ناتمام (Feature Branch و Feature Flags)

GitHub Flow استانداردش اینه:

• برنچ هست، ولی کوتاه‌عمر

• فیچرهای نیمه‌کاره با Feature Flag merge می‌شوند (flag OFF)
  

بهترین تمرین‌ها برای Flag

• default OFF

• قابلیت rollout (درصدی/گروهی/per-tenant)

• لاگ و متریک برای مسیر flagged

• برنامه جمع کردن flag بعد از rollout (flag debt)
  

مرحله 3: تست‌ها (کجا و چطور)

A) لوکال (توسعه‌دهنده)

• lint/format

• unit

• quick smoke
  
  

B) CI روی PR (استاندارد Minimum)

این‌ها باید “Required checks” باشند:

• Build ✅

• Unit tests ✅

• Lint / Static analysis ✅

• Dependency/secret scan ✅

• Integration/contract tests سبک ✅
  

C) بعد از merge به main

• deploy به staging (یا preview)

• smoke/e2e کوتاه روی محیط واقعی

• (اختیاری) تست‌های سنگین‌تر شبانه/دوره‌ای

3) کدریویو استاندارد

GitHub Flow = PR-centric

• PR کوچک

• ۱ reviewer کافی (۲ تا برای قسمت‌های حساس)

• Review روی:
  

  • correctness
    
    

  • تست کافی
    
    

  • backward compatibility
    
    

  • migration safety
    
    

  • flag درست
    
    

  • security impact

SLA پیشنهادی (استاندارد تیم‌های چابک):

• PRهای کوچک: همان روز

4) Merge و محافظت از main

Branch protection استاندارد

• Required status checks (CI باید سبز باشد)

• Required approvals (حداقل ۱)

• منع force-push

• منع merge بدون review

• squash merge یا merge commit (هر کدام، ولی consistency مهم است)
  

5) Deploy و محیط‌ها (Staging / Preview / Prod)

مدل‌های رایج در GitHub Flow

مدل 1) Preview Environments برای هر PR (استاندارد مدرن)

• با باز شدن PR:
  
  

  • یک محیط موقت ساخته می‌شود (URL جدا)
    
    

• QA و PO همانجا تست می‌کنند

• با merge: محیط حذف می‌شود

مدل 2) Staging مشترک

• بعد از merge، main اتومات روی staging می‌رود

• QA روی staging تست می‌کند

✅ اگر زیرساخت دارید، Preview per PR بهترین تجربه را می‌دهد.

6) QA در GitHub Flow دقیقاً کجاست؟

QA معمولاً اینجاهاست:

1. روی PR Preview (بهترین حالت)

2. یا بعد از merge روی staging

استاندارد عملی

• QA دستی بیشتر روی:
  

  • regression مسیرهای حیاتی
    
    

  • exploratory
    
    

  • UX
    
    

  • cross-device/browser
    
    

• اتوماسیون بیشتر روی:
  
  

  • smoke
    
    

  • e2e کوتاه
    
    

  • contract/integration
    
    

7) Release به Production

GitHub Flow دو حالت استاندارد دارد:

حالت A) Continuous Deployment

• هر merge به main → اتومات تا prod (با canary و flags)

حالت B) Continuous Delivery (رایج‌تر)

• main همیشه آماده انتشار است

• انتشار با “promote” یک artifact انجام می‌شود (مثلاً دکمه Release)

نکته مهم: در هر دو، main deployable می‌ماند.

8) Tag گذاری و نسخه‌دهی

استانداردها

• Tag روی همان commit که به production رفت
  
  

  • vMAJOR.MINOR.PATCH (SemVer)
    
    

  • یا release-YYYY.MM.DD.N (CalVer)
    
    

Release notes

• از PR title + labels (feature/fix/breaking)

• یا Conventional Commits برای اتومات‌سازی version bump
  

9) Hotfix / Bugfix در GitHub Flow

چون main منبع واحد است، مسیر سریع:

1. برنچ از main: hotfix/... یا fix/...

2. PR کوچک + CI + review سریع

3. merge به main

4. deploy سریع (در صورت نیاز bypass حداقلی با policy مشخص)

5. tag patch نسخه

اگر prod روی commit قدیمی باشد (کمتر رایج در GH Flow):

• موقت release/<version> از tag ساخته می‌شود، patch می‌خورد، deploy می‌شود، بعد patch به main هم برمی‌گردد.

10) Multi-tenant و نسخه‌ها در GitHub Flow

استاندارد بهتر (پیشنهادی)

• یک کدbase + یک pipeline

• تفاوت‌ها با:
  
  

  • feature flags per tenant
    
    

  • config per tenant
    
    

  • gradual rollout per tenant
    
    

اگر tenantها نسخه‌های جدا لازم دارند

• این برخلاف روح GH Flow است و هزینه را زیاد می‌کند

• راه بهتر: tenantها را با flag/config کنترل کنید نه با شاخه‌های طولانی

• اگر مجبور شدید: release branch های پشتیبانی (maintenance) ایجاد می‌شود، ولی این شما را به سمت GitFlow می‌برد.
  

11) Database migrations (خیلی مهم)

همان استاندارد امن:

• Expand → Backfill → Switch → Contract
  

• deploy باید backward compatible باشد

• اگر rolling deploy دارید، کد جدید و قدیم باید هم‌زیست باشند
  

12) Code Freeze در GitHub Flow

اصولاً فریز طولانی نداریم.

جایگزین استاندارد

• release cut = انتخاب یک commit/artifact برای prod

• بقیه کارها می‌توانند merge شوند ولی:
  
  

  • پشت feature flag OFF بمانند
    
    

• اگر مجبورید:
  
  

  • فریز کوتاه در پنجره انتشار (ساعت‌ها)
    
    

  • نه چند روز
    
    

13) کنترل ریسک: Canary / Blue-Green / Rollback

استانداردهای توصیه‌شده:

• canary (درصدی یا per-tenant)

• blue-green

• rollback به tag قبلی

• ولی برای DB: rollback سخت → پس expand/contract حیاتی است

14) امنیت، Compliance، Observability

امنیت (گیت‌ها)

• secret scanning

• dependency scanning

• SAST سبک

• policy برای تغییرات حساس (۲ reviewer)

observability

• logging ساختاریافته

• metrics + alerting

• tracing (اگر microservices)

• post-deploy smoke در prod

15) “Definition of Done” در GitHub Flow

یک تغییر Done است اگر:

• PR merge شده به main

• CI سبز

• review انجام شده

• روی preview/staging تست شده (حداقل smoke)

• release notes قابل تولید است

• مانیتورینگ/لاگ قابل اتکا دارد

• flag plan دارد (enable/cleanup)

16) خلاصه خیلی کوتاه GitHub Flow (کل مسیر)

1. branch از main

2. تغییر کوچک + تست لوکال

3. PR → CI checks + review

4. merge به main

5. deploy به staging/preview + QA

6. release/prod deploy (اتومات یا promote)

7. tag version + release notes

8. monitor + rollback/roll-forward

9. cleanup flags + debt
   
   GitLab Flow ترکیبی از:

• سادگی GitHub Flow
  
  

• ساختار محیطی (environment-based)

• و کنترل انتشار شبیه GitFlow

🔹 تفاوت اصلی با GitHub Flow:
در GitLab Flow معمولاً علاوه بر main، شاخه‌های محیطی مثل:

• production

• staging

• preprod
  

هم داریم.

🧱 1) ساختار شاخه‌ها در GitLab Flow

حالت استاندارد (Environment-based)

شاخه‌های دائمی

• main → توسعه جاری

• staging → نسخه آماده تست نهایی

• production → آنچه روی prod است

شاخه‌های موقت

• feature/<ticket>

• fix/<ticket>

• hotfix/<ticket>
  

🔄 2) جریان کامل توسعه (End-to-End)

مرحله 1️⃣: شروع فیچر

از main:

feature/ABC-123-payment-refactor

اینجا چه چیزهایی هندل می‌شود؟

• Feature Flag اگر فیچر بزرگ است

• برنامه migration دیتابیس

• تست‌های مورد نیاز

مرحله 2️⃣: توسعه + تست

تست‌های لوکال

• unit

• lint

• type check
  

CI روی Merge Request (MR)

گیت‌های استاندارد:

• Build ✅

• Unit tests ✅

• Static analysis ✅

• Security scan (SAST/Dependency) ✅

• Integration test سبک ✅

MR باید سبز باشد تا merge شود.

مرحله 3️⃣: Merge به main

وقتی MR approve شد:

feature → main

🔹 main باید همیشه stable و deployable باشد.

🚀 3) حرکت بین محیط‌ها (جذاب‌ترین بخش GitLab Flow)

بعد از merge به main:

مسیر استاندارد:

main → staging → production

مرحله 4️⃣: انتقال به staging

دو مدل رایج:

مدل A) Merge-based promotion

merge main → staging

مدل B) Tag-based promotion (بهتر)

• یک commit از main انتخاب می‌شود

• همان commit به staging deploy می‌شود
  

QA اینجا تست می‌کند:

• regression

• smoke

• exploratory

• performance sanity

مرحله 5️⃣: انتشار به production

وقتی staging تأیید شد:

staging → production

یا promote همان artifact.

سپس:

• Tag زده می‌شود:
  
  v1.4.2

🧪 4) QA دقیقاً کجاست؟

در GitLab Flow سه نقطه دارد:

1️⃣ Preview Environment (برای هر MR)
2️⃣ روی staging
3️⃣ smoke بعد از production deploy

استاندارد حرفه‌ای:

• Preview per MR (اگر زیرساخت دارید)

• QA سنگین‌تر روی staging

• smoke سریع روی prod

🛠 5) Hotfix در GitLab Flow

سناریو: باگ روی Production

از production:

hotfix/1.4.3-critical-fix

جریان:

hotfix → production

hotfix → main

hotfix → staging

سپس:

• Tag:
  
  v1.4.3
  

این یکی از تفاوت‌های مهم با GitHub Flow است:
چون شاخه production داریم، hotfix از آن زده می‌شود.

🏷 6) Tag گذاری و نسخه‌دهی

استانداردها:

• SemVer:
  
  vMAJOR.MINOR.PATCH

• یا Calendar Versioning

Tag باید:

• روی commit production باشد

• artifact traceable باشد

Release Notes:

• از MRها

• یا Conventional Commits

🧩 7) Multi-Tenant در GitLab Flow

حالت استاندارد توصیه‌شده:

• یک کدbase

• یک production

• تفاوت tenantها با:
  
  

  • feature flags
    
    

  • config per tenant
    
    

  • gradual rollout
    
    

اگر tenant نسخه متفاوت بخواهد:

• می‌توانید شاخه‌های maintenance داشته باشید:
  
  production-tenant-A
  production-tenant-B

اما:
⚠ پیچیدگی و هزینه شدیداً بالا می‌رود.

بهترین استاندارد:
کنترل با config/flag نه با branch.

🗄 8) Database Migration استاندارد

همان قاعده طلایی:

Expand → Migrate → Contract

چون در GitLab Flow:

• ممکن است main جلوتر از production باشد

• باید migrationها backward compatible باشند

❄ 9) Code Freeze

در GitLab Flow ممکن است:

• هنگام آماده‌سازی staging → production

• فریز کوتاه روی staging داشته باشید

اما:

• main می‌تواند جلو برود

• فقط merge به staging متوقف می‌شود

این مدل فریز سالم‌تر از GitFlow است.

🛡 10) امنیت و Compliance

در CI GitLab معمولاً این stageها داریم:

• build

• test

• security

• package

• deploy

Security Gates:

• SAST

• Dependency scan

• Secret detection

• Container scan

📊 11) Rollout و کنترل ریسک

استانداردهای توصیه‌شده:

• Canary deployment

• Blue/Green

• Feature flags rollout

• Auto rollback بر اساس metrics
  

🧠 12) Definition of Done در GitLab Flow

یک تغییر Done است اگر:

• MR approve شده

• CI سبز

• merge به main

• deploy به staging

• QA تأیید

• deploy به production

• tag خورده

• مانیتورینگ سالم است

📌 خلاصه نهایی GitLab Flow

feature → main → staging → production

Hotfix:

production → hotfix → production

                ↘ main

                ↘ staging

در این مدل، هر محیط (Environment) یک شاخه جدا دارد.
مثلاً:

main        → توسعه

staging     → تست

production  → محیط واقعی

و کد با merge از یک محیط به محیط بعدی «حرکت» می‌کند.

🧱 1) ساختار شاخه‌ها

شاخه‌های دائمی (بر اساس محیط‌ها)

• main یا dev

• staging

• production

شاخه‌های موقت

• feature/<ticket>

• fix/<ticket>

• hotfix/<ticket>

🔄 2) جریان کامل توسعه (End-to-End)

مرحله 1️⃣ شروع فیچر

از main:

feature/ABC-123-add-discount

اینجا چه چیزهایی باید هندل شود؟

• اگر فیچر بزرگ است → Feature Flag تعریف شود

• اگر تغییر DB دارد → migration plan (expand/contract)

• تست‌ها مشخص شوند

مرحله 2️⃣ توسعه + تست

لوکال

• unit

• lint

• type check
  

CI روی PR به main

گیت‌های استاندارد:

• Build

• Unit tests

• Static analysis

• Security scan

• Integration tests سبک

بعد از سبز شدن:

feature → main

🚀 3) حرکت بین محیط‌ها

مرحله 3️⃣ انتقال به staging

وقتی آماده تست شد:

main → staging

یا با merge مستقیم
یا با انتخاب commit خاص

روی staging چه اتفاقی می‌افتد؟

• Deploy اتومات

• QA:
  
  

  • regression
    
    

  • exploratory
    
    

  • smoke
    
    

  • performance sanity
    
    

مرحله 4️⃣ انتقال به production

بعد از تایید QA:

staging → production

• Deploy prod

• Tag نسخه:
  v1.6.0

🧪 4) QA دقیقاً کجاست؟

QA در این مدل معمولاً:

1️⃣ روی staging
2️⃣ smoke سریع بعد از prod

اگر زیرساخت دارید:

• Preview environment برای هر feature branch هم می‌شود اضافه کرد

🛠 5) Hotfix در Environment Branching

اگر باگ در production پیدا شد:

از production:

hotfix/critical-fix

جریان:

hotfix → production

hotfix → staging

hotfix → main

چرا merge به همه؟
چون اگر فقط روی production بماند، drift ایجاد می‌شود.

🏷 6) نسخه‌دهی و Tag

Tag باید:

• روی production زده شود

• قابل trace به commit و artifact باشد

استاندارد:

vMAJOR.MINOR.PATCH

Release notes:

• از PRها

• یا Conventional Commits
  

🧩 7) Multi-Tenant در Environment Branching

حالت استاندارد

• یک production branch

• تفاوت tenantها با:
  
  

  • config per tenant
    
    

  • feature flag per tenant
    
    

  • rollout تدریجی
    
    

حالت پیچیده‌تر

اگر tenant نسخه جدا بخواهد:

• ممکن است branch های production جدا بسازید
  
  production-tenant-A
  production-tenant-B

اما:
⚠️ هزینه نگهداری بالا و merge پیچیده می‌شود.

بهترین روش:
کنترل با config نه branch.

🗄 8) Database Migration

خیلی مهم چون چند branch دائمی داریم.

قانون طلایی:

• migration باید backward compatible باشد

• چون main ممکن است جلوتر از production باشد

روش استاندارد:

1. Add column

2. Deploy

3. Backfill

4. Switch code

5. Remove old column

❄ 9) Code Freeze

در این مدل معمولاً:

• هنگام آماده‌سازی staging → production
  فریز کوتاه روی staging

اما:

• main می‌تواند جلو برود

• فقط merge به staging موقتاً متوقف می‌شود

🛡 10) امنیت و Quality Gates

در CI:

• Build

• Test

• Security scan

• Container scan

• Secret detection
  

برای merge به production:

• Manual approval

• Change log بررسی شود

📊 11) Rollout و کنترل ریسک

توصیه‌ها:

• Canary deploy

• Blue/Green

• Feature flags

• Auto rollback بر اساس metrics

🧠 12) Definition of Done

یک تغییر Done است اگر:

• merge به main

• merge به staging

• QA تایید

• merge به production

• tag زده شده

• مانیتورینگ سالم

⚠ مشکلات رایج Environment Branching

چیزهایی که باید حواستان باشد:

1️⃣ Drift بین branchها
2️⃣ Merge conflict زیاد
3️⃣ تاخیر در انتقال تغییرات
4️⃣ Hotfix فراموش شود به main برگردد
5️⃣ Release بزرگ و ریسکی شود

📌 خلاصه مسیر کامل

feature → main → staging → production

Hotfix:

production → hotfix → production

                      ↘ staging

                      ↘ main

غیر از مدل‌هایی که گفتیم (Trunk-Based, GitFlow, GitHub Flow, GitLab Flow, Environment Branching)، چند مدل معروف و کاربردی دیگه هم هست که در دنیای واقعی استفاده می‌شن.

من همه مدل‌های شناخته‌شده و پرکاربرد رو دسته‌بندی می‌کنم 👇

1️⃣ 🧱 Centralized Workflow (مدل ساده متمرکز)

4

ایده:

• فقط یک شاخه اصلی (main)

• همه مستقیم روی آن commit می‌زنند

مناسب برای:

• تیم‌های خیلی کوچک

• پروژه‌های داخلی ساده

• migration از SVN

ضعف:

• ریسک بالا

• بدون isolation

• مناسب CI/CD حرفه‌ای نیست

2️⃣ 🌲 Forking Workflow (مدل متن‌باز)

4

ایده:

• هر توسعه‌دهنده یک fork جدا دارد

• تغییرات از طریق Pull Request به ریپوی اصلی می‌آید

مناسب برای:

• پروژه‌های Open Source

• سازمان‌های بزرگ با دسترسی محدود

مزیت:

• ایزوله کامل

• امنیت بالا

3️⃣ 🏷 Release Train Model

4

ایده:

• انتشار در زمان‌های ثابت (مثلاً هر دو هفته)

• هر چیزی که آماده باشد سوار قطار می‌شود

معمولاً همراه با:

• Trunk-Based

• یا GitHub Flow

مناسب برای:

• SaaS با ریلیز منظم

• تیم‌های بزرگ که cadence مشخص دارند

4️⃣ 🧩 Monorepo + Trunk Strategy

4

ایده:

• همه سرویس‌ها در یک repo

• یک trunk

• تغییرات کوچک و سریع

استفاده توسط:

• Google

• Meta

نیاز:

• CI بسیار قوی

• تست‌های سریع

5️⃣ 🔀 Scaled GitFlow (مدل سازمانی بزرگ)

نسخه‌ای از GitFlow با:

• maintenance branch

• support branch

• long term support (LTS)

مناسب برای:

• نرم‌افزارهای on-premise

• محصولاتی با نسخه‌های همزمان فعال

6️⃣ 🧠 Hybrid Flow (مدل ترکیبی)

خیلی از سازمان‌ها یک مدل pure ندارند.

مثال‌ها:

• Trunk-Based + Environment Branch

• GitHub Flow + Release Train

• GitFlow ساده‌شده بدون develop

در عمل، اکثر شرکت‌ها hybrid هستند.

7️⃣ 🔐 Long-Term Support Branching (LTS Model)

ایده:

• یک نسخه پایدار برای مشتریان سازمانی

• نسخه جدید برای مشتریان عمومی

مثلاً:

main

lts/1.0

lts/2.0

نیازمند:

• backport مرتب

• تیم جدا برای پشتیبانی نسخه قدیمی

8️⃣ 🚀 Progressive Delivery Model

این بیشتر استراتژی انتشار است تا برنچینگ، ولی مهمه:

• Feature Flags

• Canary

• A/B Testing

• Gradual Rollout

معمولاً روی:

• Trunk-Based

• GitHub Flow

سوار می‌شود.

9️⃣ 🧪 Experimental Branching Model

برای R&D:

• branchهای آزمایشی بلندمدت

• merge فقط اگر موفق شد

کمتر رایج در محصول production-critical.

📊 خلاصه مدل‌های معروف

مدل

پیچیدگی

مناسب برای

Centralized

کم

تیم کوچک

GitHub Flow

کم

SaaS سریع

Trunk-Based

کم

CI/CD پیشرفته

GitFlow

زیاد

ریلیز دوره‌ای

GitLab Flow

متوسط

سازمان محیط‌محور

Environment Branching

متوسط

چند محیط سازمانی

Forking

متوسط

Open Source

Release Train

کم

ریلیز منظم

LTS Branching

زیاد

Enterprise

Hybrid

متغیر

سازمان‌های واقعی