مرحله بندی خطوط لوله و انتشار

1) چرا شما نیاز به مرحله بندی خط لوله دارید

• مونتاژ و انتشار تکرارپذیری ؛
• بازخورد سریع و قابل پیش بینی ؛
• به حداقل رساندن خطر (نورد مترقی، phicheflags، عقبگرد) ؛
• انطباق و کنترل تغییر

2) جریان منبع مرجع (سطح بالا)

1. PR → چک های اتوماتیک (خط، واحد، SAST، مجوز).
2. ساخت → تصویر قطعی/بسته، امضا و SBOM.
3. تست در Ephemeral → پیش نمایش محیط در هر PR.

• رسوب تصویر ؛
• قرارداد، ادغام، e2e-test ؛
• DAST/IAST، رگرسیون، بارگذاری دود ؛
• UAT/QA دستی در صورت لزوم.
• 5. نامزد انتشار (RC) → پنجره یخ → تولید (قناری/آبی سبز).
• 6. چک های پس از استقرار و ارسال خودکار به بودجه SLO/خطا.
• 7. Runbook/Changelog → انتشار بسته و گذشته نگر.

3) قالب خط لوله استاندارد YAML (سرعت شاتر)

yaml
.ci/release.pipeline.yml stages: [verify, build, test, stage, approve, release, post]

verify:
- run: make lint test:unit sbom sast sca build:
- run:
docker build -t registry/app:$GIT_SHA.
cosign sign registry/app:$GIT_SHA oras push registry/sbom:$GIT_SHA sbom.json test:
- run: make test:contract test:integration
- run: make deploy:preview && make test:e2e stage:
- run: make deploy:staging IMAGE=registry/app:$GIT_SHA
- run: make test:e2e:staging && make dast approve:
manual gate: CAB/QA lead
- type: manual required_roles: [release_manager, qa_lead]
release:
- run: make release:canary TRAFFIC=5%
- run: make release:progressive STEPS="5,25,50,100"
post:
- run: make verify:slo && make notify && make create:changelog

4) گیتس و معیارهای آمادگی (گیتس کیفیت)

کد و امنیت: خطوط، پوشش، SAST/SCA، سیاست وابستگی، بدون بحرانی/بالا.
قراردادها: سازگاری طرح ها (API/events)، چک های Pact/Buf.
آزمون: واحد/ادغام/E2E P آستانه، ثبات (پوسته پوسته شدن نرخ).
دود بار: p95/p99 در بودجه، بدون تخریب.
DAST/IAST: هیچ یافته بحرانی، سناریوهای تست قلم برای مسیرهای حساس.
مشاهده: داشبورد/هشدار «به عنوان کد» به روز شده، runbooks متصل شده است.
CAB/UAT: تایید در پنجره های انتشار (در صورت نیاز توسط نظارتی/کسب و کار).

5) استراتژی های انتشار

Canary - افزایش تدریجی در سهم ترافیک (5٪ → 25٪ → 50٪ → 100٪)، خودکار رول جلو/عقب برای SLO و ناهنجاری ها.
آبی سبز - رسانه های موازی ؛ سوئیچ فوری، بازگشت ساده.
ویژگی پرچم - گنجاندن منطقی از ویژگی های بدون redeploy; «پرتاب تاریک» و قابلیت A/B.
سایه/ترافیک معکوس - ترافیک منفعل به نسخه جدید بدون تاثیر بر کاربران اجرا می شود.
استقرار حلقه - امواج توسط منطقه/مستاجر.

6) بازپرداخت و انتشار سیاست امنیتی

بازگشت خودکار توسط عوامل: رشد نرخ خطا، p95/TTFB بالاتر از آستانه، رشد 5xx/timeout، اسپایک DLQ.
rollback دستی: فرمان '/rollback <service> <sha> 'در chatbot، یک دکمه در کنسول انتشار.
پنجره های یخ: انتشار به رویدادهای بحرانی (مسابقات/مسابقات اوج) ممنوع است.
Changelog & Release Notes: تولید از برچسب های PR، SemVer، اجزای سازنده، مهاجرت.

7) مهاجرت پایگاه داده و سازگاری

1. اضافه کردن زمینه های سازگار/شاخص

2. استقرار برنامه (خواندن/نوشتن به هر دو طرح) ؛

3. مهاجرت داده ها با مشاغل پس زمینه ؛

4. قدیمی را حذف کنید.

طرح ها versioned، مهاجرت idemotent، خشک اجرا در مرحله بندی.

حفاظت از SQL مخرب: نیاز به پرچم/تایید، پشتیبان گیری خودکار و برنامه چک.

8) Ficheflags و فعال سازی مترقی

پرچم های عملیات جداگانه (برای عملیات ایمن) و پرچم های محصول.
ورود توسط مخاطبان: درصد، جغرافیایی، مستاجر، نقش.
معیارهای پرچم: تاثیر تبدیل، تاخیر، خطاها.
در صورت بروز مشکل، convolution پرچم سریعتر از rollback است.

9) قابلیت مشاهده به عنوان بخشی از انتشار

ردیابی: پایان دادن به پایان 'trace _ id' از دروازه به DB/صف ؛ مقایسه نسخه های قدیمی و جدید

معیارها: p50/p95/p99، نرخ خطا، RPS، اشباع، DLQ، retray، زمان به کیف پول/KPI کسب و کار.
سیاهههای مربوط: ساختار، PII پوشش، 'درخواست _ id' همبستگی.
هشدارها: بودجه SLO، صفحات فوری در تماس، انتشار خودکار کانولوشن.

10) امنیت زنجیره تامین

SBOM برای هر ساخت، ذخیره سازی و اتصال به برچسب انتشار.
امضای تصویر (cosign)، تأیید در یک خوشه (پذیرش سیاست).
گواهی SLSA: منشاء مصنوعات قابل اثبات.
Policy-as-Code (OPA/Conftest): انکار پیش فرض برای PR های زیربنایی.
اسرار: فقط KMS، نشانه های کوتاه مدت، چرخش خط لوله.

11) تغییر کنترل و فرآیندها

RFC → CRQ → CAB: ما در مورد تغییر مستند رفتار/قراردادها از قبل توافق داریم.
تقویم انتشار: پنجره های قابل مشاهده توسط محصول/منطقه/تیم.
Runbooks: برای هر جزء - روش برای فعال کردن/نورد تماس/تشخیص.
Postmortem/Retro: پس از انتشار قابل توجه - تجزیه و تحلیل و عمل.

12) پروفایل های تست مرحله بندی

تغییرات ناسازگار API/Events-Blocks.
Integration/e2e: سناریوهای «واریز»، «KYC»، «برداشت».
دود بار: قله نماینده ؛ ما محدودیت منابع را کنترل می کنیم.
سناریوهای هرج و مرج: قطع ارتباط ارائه دهنده، افزایش تاخیر، flappings شبکه.
نظارت مصنوعی: معاملات «آزمایشی» در یک برنامه.

13) نمونه Makefile از اهداف انتشار (قطعه)

makefile release: verify build test stage approve prod post verify:
@make lint test:unit sbom sast sca build:
docker build -t $(IMG).
cosign sign $(IMG)
test:
@make test:contract test:integration deploy:preview test:e2e stage:
kubectl apply -k deploy/staging approve:
@echo "Waiting for QA/CAB approval..."
prod:
make release:canary TRAFFIC="5 25 50 100"
post:
@make verify:slo notify changelog

14) نقش ها و مسئولیت ها

توسعه دهنده/تیم: کیفیت کد، تست، مهاجرت، runbooks.
QA: سناریوهای UAT/رگرسیون، کنترل کیفیت در دروازه ها.
SRE/Platform: قابلیت اطمینان خط لوله، قابلیت مشاهده، سیاست ها.
مدیر انتشار: تقویم، ویندوز، CAB، راه حل نهایی.
امنیت: SAST/DAST/SCA، زنجیره تامین، سیاست مخفی.

15) مدل بلوغ انتشار

1. پایه - چک های دستی، نسخه های نادر، بازپرداخت دشوار است.
2. پیشرفته - استاندارد CI/CD، مرحله بندی کانتور، قناری/آبی سبز، نسخه های مکرر.
3. کارشناس - تحویل مترقی توسط مستاجران/مناطق، ویژگی های پرچم اول، سیاست به عنوان کد، SLO خودکار آپلود، ردیابی کامل و SLSA.

16) نقشه راه پیاده سازی

M0-M1 (MVP): قالب خط لوله, ساخت + نشانه + SBOM, مرحله بندی استقرار, تست های اولیه و دروازه.
M2-M3: canary/blue-green، پیش نمایش در هر PR، تست قرارداد، DAST، چک های مصنوعی.
M4-M6: پلت فرم پرچم، ترافیک سایه، سیاست به عنوان کد، بازگشت خودکار، تقویم انتشار + CAB گردش کار.
M6 +: استقرار حلقه توسط منطقه، صدور گواهینامه SLSA و پذیرش دقیق، اتوماسیون کامل از runbooks.

17) چک لیست قبل از انتشار

• تصویر امضا شده، SBOM بارگذاری شده و آزاد شده است.
• قراردادها سازگار هستند، تست ها سبز هستند، e2e در مرحله اجرا گذشت.
• مهاجرت بررسی شده (خشک اجرا)، پشتیبان گیری آماده، طرح رول بک شرح داده شده است.
• داشبورد/هشدار به روز شده است، دروازه های SLO فعال هستند.
• Runbook و Changelog منتشر شد، پنجره های انتشار موافقت کردند.
• پرچم های ویژگی برای فعال سازی مترقی پیکربندی شده اند.
• محدودیت های انجماد برآورده شده است، در تماس آماده است.

نتیجه گیری مختصر

یک خط لوله مرحله بندی به خوبی طراحی شده، نسخه ها را به یک روال قابل کنترل تبدیل می کند: قالب های یکنواخت، دروازه های با کیفیت روشن، یک زنجیره تامین امن، نورد مترقی و مشاهده پذیری، خطر را کاهش می دهد و زمان تغییر در تولید را کاهش می دهد، در حالی که کنترل کیفیت و معیارهای تجاری را حفظ می کند.