Release Rings: Target Architecture vs Runtime Activation

1. مسئله: «منتشر شد» یک وضعیت واحد نیست

در سامانه‌های واقعی، جمله‌ی «نسخه منتشر شد» اطلاعات کافی نمی‌دهد. ممکن است artifact جدید روی یک target مستقر شده باشد اما feature path هنوز برای هیچ کاربری فعال نباشد؛ ممکن است همان feature فقط برای یک cohort محدود فعال باشد؛ یا حتی target architecture نسخه‌ی جدیدی را طلب کند ولی runtime هنوز روی topology یا artifact قبلی کار کند. اگر این حالت‌ها را در یک ستون «Released = Yes» جمع کنیم، تیم نمی‌تواند توضیح دهد دقیقاً چه چیزی، کجا، برای چه کسی و با چه شواهدی فعال است.

در این درس واحد تحلیل «release ring» است، اما ring را معادل environment نمی‌گیریم. یک ring می‌تواند یک گروه منطقی از کاربران، stampها، regionها، tenantها یا deployment targetها باشد. هدف، ساختن یک مدل مشاهده‌پذیر است که intended state را از observed state جدا کند و هر transition را با شواهد مستقل قابل review نگه دارد.

2. Release Ring را از Environment جدا کن

Environment معمولاً مرزی مانند development، staging یا production را بیان می‌کند؛ ring مرز rollout و exposure است. ممکن است چند ring در یک production environment وجود داشته باشند یا یک ring روی چند target فیزیکی پخش شود. بنابراین نام environment به تنهایی نه audience را ثابت می‌کند، نه blast radius را، نه ترتیب promotion را.

در Release Ring Activation Matrix v1 برای هر ردیف، ring identity و environment map جدا ثبت می‌شوند. این تفکیک جلوی یک خطای رایج را می‌گیرد: این‌که «چون روی production است، پس برای همه فعال است». در این مدل production فقط محل اجراست؛ activation و cohort شواهد دیگری لازم دارند.

3. Target Architecture یعنی Intended State

Target architecture پاسخ می‌دهد «این ring قرار است در چه وضعیت معماری قرار بگیرد؟». این intent می‌تواند topology version، target revision، dependency shape یا deployment stamp مطلوب را مشخص کند. Target architecture مشاهده‌ی runtime نیست؛ یک baseline مورد انتظار است که باید با شواهد observed مقایسه شود.

برای قابل‌ردیابی بودن، intent را با revision یا hash نگه دارید. اگر target architecture تغییر کرد ولی runtime هنوز همگرا نشده است، وضعیت را «drift» یا «convergence open» ثبت کنید. تغییر سند هدف نباید باعث شود runtime قبلی به‌طور روایی «درست» به نظر برسد.

4. Artifact Deployment را مستقل ثبت کن

استقرار artifact فقط ثابت می‌کند یک build/version در target مورد نظر قرار گرفته یا در inventory دیده می‌شود. این واقعیت به‌تنهایی نمی‌گوید feature path آن artifact فعال است. نسخه، digest، deployment stamp و deployment evidence باید مستقل ثبت شوند.

در matrix، desired artifact و observed artifact را مقایسه کنید. اگر target معماری نسخه‌ی B را می‌خواهد ولی ring هنوز نسخه‌ی A را اجرا می‌کند، این artifact drift است. برای رفع آن یا باید runtime را به target برسانید یا target را از مسیر change control تغییر دهید؛ حذف mismatch از گزارش مجاز نیست.

5. Runtime Activation را از وجود کد جدا کن

Feature flags و سازوکارهای مشابه اجازه می‌دهند رفتاری که در code/artifact وجود دارد در runtime روشن، خاموش یا برای audience خاصی فعال شود. بنابراین «artifact جدید deployed است» با «feature فعال است» هم‌معنا نیست. این جدایی یکی از محورهای اصلی این درس است.

سه وضعیت ساده‌ی آموزشی DISABLED، PARTIAL و ENABLED کافی‌اند تا تفاوت دیده شود. اگر artifact جدید deployed باشد اما feature disabled بماند، ردیف باید DEPLOYED_NOT_ACTIVATED را نشان دهد، نه «fully released». اگر activation جزئی است، cohort باید مشخص شود.

6. Cohort و Population بخشی از شواهد Activation هستند

Activation بدون audience ناقص است. «فعال» برای چه کسی؟ internal users، یک tenant، یک region، درصدی از traffic یا همه‌ی کاربران؟ در ring matrix، population و cohort assignment بخشی از observed state هستند.

اگر desired activation برابر PARTIAL است، cohort مورد انتظار باید با cohort مشاهده‌شده تطبیق داشته باشد. فعال شدن برای audience بزرگ‌تر از برنامه می‌تواند cohort drift ایجاد کند حتی اگر artifact و target architecture کاملاً درست باشند. blast radius از همین مرز ساخته می‌شود.

7. Health Gate و Bake Window را Evidence نگه دار

Progressive exposure بدون health evidence فقط افزایش مرحله‌ای ریسک است. برای هر ring باید معلوم باشد کدام signalها بررسی شده‌اند، در چه windowای پایدار بوده‌اند و آیا شرط خروج ring برآورده شده است. approval انسانی می‌تواند بخشی از governance باشد، اما جایگزین health signal نیست.

در این درس threshold عددی عمومی تجویز نمی‌شود. SLO، error budget، latency، business KPI یا synthetic probe باید از policy واقعی سیستم بیایند. matrix فقط می‌خواهد evidence و نتیجه‌ی gate مستقل باشند تا یک approval سبز نتواند health failure را پنهان کند.

8. Approval Evidence با Health Evidence یکی نیست

Approval می‌گوید یک شخص یا policy transition را مجاز دانسته است؛ health evidence می‌گوید runtime چه رفتاری نشان داده است. ممکن است approval وجود داشته باشد و health fail شود. در این حالت، promotion باید همچنان hold یا rollback شود، چون approval یک مشاهده‌ی فنی نیست.

برعکس، ممکن است health خوب باشد اما policy برای آن transition approval صریح بخواهد. آن‌وقت promotion از نظر فنی آماده است اما از نظر governance هنوز eligible نیست. matrix این دو را در ستون‌های جدا نگه می‌دارد تا دلیل توقف دقیق باشد.

9. Drift را Localization کن، نه این‌که کل Release را «خراب» بنامی

وقتی intended و observed state متفاوت‌اند، ابتدا مشخص کنید mismatch در کدام dimension است: target topology، artifact version، activation، cohort یا configuration. برچسب کلی «deployment failed» معمولاً مسیر repair را مبهم می‌کند.

target drift یعنی observed topology با target intent نمی‌خواند. artifact drift یعنی version/digest اشتباه است. activation drift یعنی runtime enablement با intent متفاوت است. cohort drift یعنی audience واقعی از assignment برنامه‌ریزی‌شده منحرف شده است. یک ring می‌تواند بیش از یک drift همزمان داشته باشد.

10. Failure Probe: Deployed اما Disabled

یک مورد عمداً گمراه‌کننده در Lab وجود دارد: artifact جدید با موفقیت deployed شده، deployment log سبز است، اما feature برای cohort مورد نظر disabled باقی مانده است. اگر فقط به deployment status نگاه کنید، به اشتباه آن را released می‌نامید.

پاسخ evidence-first باید دو واقعیت را همزمان نگه دارد: deployment موفق است و activation هنوز انجام نشده است. transition تا رفع activation mismatch در حالت HOLD می‌ماند. این probe ثابت می‌کند deployment و runtime activation دو state مستقل‌اند.

11. Failure Probe: Approval سبز ولی Health قرمز

در probe دوم، approval ثبت شده اما health gate fail است. تصمیم درست این نیست که approval را «قوی‌تر» از signal فنی بدانیم. اگر policy rollback trigger را فعال کرده باشد، rollback candidate می‌شود؛ در غیر این صورت حداقل promotion متوقف می‌شود.

این مثال نشان می‌دهد matrix باید evidence ordering داشته باشد: observed health و reconciliation شرط فنی‌اند؛ approval شرط governance است. هیچ‌کدام نباید silently به دیگری تبدیل شود.

12. Release Ring Activation Matrix v1 را ردیفی بساز

حداقل ردیف شامل این فیلدهاست: Ring، Intended Target، Environment، Desired/Observed Artifact، Deployment Evidence، Desired/Observed Activation، Cohort، Health Gate، Approval، Drift و Transition Decision. کنار هر نتیجه، منبع evidence یا وضعیت UNKNOWN را ثبت کنید.

این artifact برای «فهمیدن آنچه واقعاً در حال اجراست» ساخته شده است. بنابراین summary سبز تنها وقتی معتبر است که row-level evidence آن را پشتیبانی کند. اگر داده‌ای ندارید، UNKNOWN_INSUFFICIENT_EVIDENCE از حدس بهتر است.

13. Promotion، Hold و Rollback را از Evidence مشتق کن

Promotion زمانی قابل دفاع است که stateهای لازم همگرا باشند، health gate عبور کرده باشد و governance لازم تکمیل شده باشد. Hold زمانی است که mismatch قابل اصلاح یا evidence ناقص وجود دارد. Rollback زمانی مطرح می‌شود که policy/trigger واقعی آن را ایجاب کند؛ این درس trigger عمومی اختراع نمی‌کند.

Reconciliation action باید با drift متناسب باشد: artifact mismatch با deploy/reconcile version، activation mismatch با اصلاح activation/flag state، target mismatch با topology reconciliation یا change-control target، و cohort mismatch با assignment correction. یک اقدام کلی «redeploy» پاسخ همه‌ی mismatchها نیست.

14. Lab: از Fixture محلی Matrix را بازسازی کن

Lab کاملاً local و synthetic است. هشت case دارد که شامل ring سالم، deployed-but-disabled، artifact drift، health failure همراه approval، target drift، cohort drift، evidence ناقص و یک transfer case با نام‌های متفاوت است. هیچ credential، endpoint زنده یا production system استفاده نمی‌شود.

ابتدا python run_checks.py را اجرا کنید تا structure fixture تأیید شود. سپس analyze_ring(case) را در starter.py پیاده‌سازی کنید و برای هر case هشت dimension مستقل برگردانید. هدف حفظ مرز evidence است، نه حفظ کردن متن درس.

15. Transfer: مدل را با Ring Name و Topology متفاوت دوباره بساز

در transfer case، نام ringها، target architecture و activation mechanism تغییر می‌کند. نباید تعداد ring، threshold یا نام‌های baseline را کپی کنید. روش باید از raw evidence دوباره ساخته شود: intent، artifact، activation، cohort، health، approval و transition.

اگر بتوانید در یک context جدید بدون تکیه بر نام‌ها یا درصدهای قبلی همان separation را حفظ کنید، outcome درس منتقل شده است. خروجی معتبر فقط وقتی بسته می‌شود که direct evidence، inference و unknownها از هم تفکیک شده باشند.