Staging-payplaynlar va relizlar

1) Nima uchun staging-paypline kerak?

• yig’ish va relizning takrorlanuvchanligi;
• tezkor va oldindan aytib bo’ladigan fidbek;
• tavakkalchilikni minimallashtirish (progressiv yoyilishlar, ficheflaglar, qaytishlar);
• komplayensga muvofiqligi va o’zgarishlarni nazorat qilish.

2) Yetkazib berishning etalon oqimi (high-level)

1. PR → avtomatik tekshiruvlar (lint, unit, SAST, litsenziyalar).
2. Build → determinizatsiya qilingan rasm/paket, imzo va SBOM.
3. Test on Ephemeral → per-PR prevyu-atrof-muhit.

• tasvir daftari;
• kontrakt-, integratsion, e2e-testlar;
• DAST/IAST, regress, yuk smoke;
• qo’lda ishlatiladigan UAT/QA.
• 5. Release Candidate (RC) → freeze window → Prod (canary/blue-green).
• 6. Post-deploy tekshirish va SLO/error budget bo’yicha avtootkat.
• 7. Runbook/Changelog → reliz va retrospektivni yopish.

3) Piplaynning standartlashtirilgan YAML-shabloni (ushlab turish)

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) Gates va tayyorlik mezonlari (Quality Gates)

Kod va xavfsizlik: lintlar, qoplama, SAST/SCA, qaramlik siyosati, «critical/high» ning yo’qligi.
Kontraktlar: sxemalarning mosligi (API/hodisa), Pact/Buf tekshiruvi.
Testlar: unit/integration/e2e p-o’tish chegarasi, barqarorlik (flake-rate).
Yuki smoke: p95/p99 byudjet doirasida, degradatsiyalar yoʻq.
DAST/IAST: hech qanday tanqidiy findings, sezgir usullar uchun pen-test stsenariylari mavjud emas.
Observability: «as code» dashbordlari/alertlari yangilandi, runbooks ilova qilindi.
CAB/UAT: reliz oynalarida tasdiqlash (agar regulyator/biznes talab qilsa).

5) Reliz strategiyalari

Canary - trafik ulushini bosqichma-bosqich oshirish (5% → 25% → 50% → 100%), SLO va anomaliyalar bo’yicha avtomatik roll-forward/rollback.
Blue-Green - parallel muhitlar; tezkor o’tkazgich, oddiy orqaga qaytish.

Feature Flags - redeploy boʻlmagan fich mantiqiy qoʻshilishi; «dark launch» va A/B. imkoniyati

Shadow/Traffic Mirroring - foydalanuvchilarga ta’sir qilmasdan yangi versiyaga passiv trafik tashlash.
Ring Deployments - mintaqalar/tenantlar bo’yicha to’lqinlar.

6) Relizlarning qaytishi va xavfsizlik siyosati

Triggerlar bo’yicha avtootkat: o’sish error-rate, ostonadan yuqori p95/TTFB, o’sish 5xx/timeout, DLQ ko’tarilishi.
Qoʻlda orqaga qaytish: chat-botda ’/rollback <service> <sha>’buyrugʻi, reliz-konsolda bitta tugma.
Freeze windows: tanqidiy voqealarni (turnirlar/eng yuqori oʻyinlar) chiqarish taqiqlangan.
Changelog & Release Notes: PR, SemVer, komponentlar, migratsiyalar.

7) DB migratsiyasi va muvofiqlik

1. mos keladigan maydonlarni/indekslarni qoʻshish;

2. ilova bo’yicha (ikkala sxemada ham o’qiydi/yozadi);

3. fon joblari bilan ma’lumotlarning ko’chishi;

4. eskisini olib tashlash.

Sxemalar versiyalashtiriladi, idempotent migratsiyasi, dry-run staging.

Protect destructive SQL: require flag/approval, avtomatik bekaplar va plan-check.

8) Fizeflaglar va progressiv faollashtirish

Ops bayroqlarini (xavfsiz foydalanish uchun) va product bayroqlarini ajrating.
Auditoriya bo’yicha kiritish: foiz, geo, tenant, rol.
Bayroqlarning metrikasi: konversiyaga ta’siri, latency, xatolar.
Muammolar bo’lganda - bayroqni orqaga qaytishdan tezroq o’rash.

9) Observability relizning bir qismi sifatida

Treyslar: gatewaydan DB/navbatlargacha’trace _ id’orqali; eski/yangi versiyalarni solishtirish.
Metriklar: p50/p95/p99, error-rate, RPS, saturation, DLQ, retray, Time-to-Wallet/Business KPI.
Loglar: strukturalangan, PII niqoblangan, «request _ id» korrelyatsiyasi.
Alertlar: SLO-byudjet, on-call shoshilinch sahifalari, relizning avto-sarlavhasi.

10) Yetkazib berish zanjiri xavfsizligi (supply chain)

Har bir bild uchun SBOM, saqlash va reliz tegiga bog’lash.
Tasvir imzosi (cosign), klasterda tekshirish (policy admission).
SLSA-attestatsiyalar: artefaktning isbotlanadigan kelib chiqishi.
Policy-as-Code (OPA/Conftest): infratuzilma PR uchun deny-by-default.
Sirlar: faqat KMS, qisqa yashaydigan tokenlar, payplaynlarda rotatsiyalar.

11) O’zgarishlarni nazorat qilish va jarayonlar

RFC → CRQ → CAB: xulq-atvor/kontraktlarning hujjatlashtiriladigan o’zgarishini oldindan kelishib olamiz.
Release Calendar: mahsulotlar/hududlar/buyruqlar boʻyicha koʻrinadigan oynalar.
Runbooks: har bir komponent uchun - yoqish/qaytarish/diagnostika protseduralari.
Postmortem/Retro: muhim relizlardan keyin - tahlil va harakatlar.

12) Staging uchun test profillari

Kontrakt (API/Events): mos kelmaydigan oʻzgarishlarni bloklaydi.
Integratsiya/e2e: «depozit», «KYC», «chiqish».
Yuklama smoke: reprezentativ cho’qqilar; resurs limitlarini kuzatib boramiz.
Xaos-stsenariylar: provayderni uzib qo’yish, latentlikni oshirish, tarmoq flappinglari.
Sintetik monitoring: jadval bo’yicha «sinov» tranzaksiyalari.

13) Reliz maqsadlarining Makefile misoli (parcha)

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) O’zbekiston Respublikasining

Dev/Team: kod sifati, testlar, migratsiyalar, runbooks.
QA: UAT/regression stsenariylari, gates’da sifat nazorati.
SRE/Platforma: payplaynlarning ishonchliligi, kuzatuv, siyosat.
Release Manager: taqvim, oynalar, CAB, yakuniy yechim.
Security: SAST/DAST/SCA, supply-chain, maxfiy siyosat.

15) Relizlarning yetuklik modeli

1. Bazaviy - qo’lda tekshirish, kamdan-kam relizlar, orqaga qaytish qiyin.
2. Ilgʻor - standartlashtirilgan CI/CD, staging-kontur, canary/blue-green, tez-tez relizlar.
3. Ekspert - tenantlar/hududlar bo’yicha progressiv yetkazib berish, feature flags-first, policy-as-code, SLO bo’yicha avtootkat, to’liq izlanish va SLSA.

16) Joriy etish yo’l xaritasi

M0-M1 (MVP): payplayn namunasi, build + sign + SBOM, staging-deploy, bazaviy testlar va gates.
M2-M3: canary/blue-green, prevyu per-PR, kontrakt-testlar, DAST, synthetic checks.
M4-M6: feature flags platforma, shadow traffic, policy-as-code, avtootkat, release calendar + CAB-workflow.
M6 +: hududlar bo’yicha ring-deployments, SLSA-attestatsiya va qat’iy admission, runbooks to’liq avtomatlashtirish.

17) Mahsulot chiqarishdan oldingi chek-varaq

• Rasm imzolangan, SBOM yuklangan va chiqarishga bog’langan.
• Shartnomalar mos keladi, testlar yashil, e2e stagingda o’tdi.
• Migratsiyalar tekshirildi (dry-run), bekap tayyor, qaytarish rejasi tasvirlangan.
• Dashbordlar/alertlar yangilandi, SLO geytlar faol.
• Runbook va Changelog nashr etildi, chiqarish oynalari kelishilgan.
• Feature flags progressiv faollashtirish uchun sozlangan.
• Freeze-cheklovlarga rioya qilindi, on-call tayyor.

Qisqacha xulosa

Yaxshi loyihalashtirilgan staging-paypline relizlarni boshqariladigan tartibga aylantiradi: yagona shablonlar, aniq quality gates, himoyalangan yetkazib berish zanjiri, progressiv yoyilishlar va kuzatish xavfni kamaytiradi va sifat va biznes-metriklar ustidan nazoratni saqlab qolgan holda ishlab chiqarishga o’zgarishlarni kiritish vaqtini qisqartiradi.