Staging-пайплайндар және релиздер

1) staging-paypline не үшін қажет

• құрастыру мен шығарудың жаңғыртылуы;
• жылдам және болжамды фидбек;
• тәуекелді барынша азайту (прогрессивті тегістеу, фичефлагтар, қайтарулар);
• комплаенске сәйкестігі және өзгерістерді бақылау.

2) Эталондық жеткізу ағыны (high-level)

1. PR → автоматты тексеру (lint, unit, SAST, лицензиялар).
2. Build → детерминирленген кескін/пакет, қолтаңба және SBOM.
3. Test on Ephemeral → per-PR алдын ала ортасы.

• бейне деплой;
• келісім-шарт, интеграциялық, e2e-тестілер;
• DAST/IAST, регрестер, жүктеме smoke;
• қажет болған жағдайда қол UAT/QA.
• 5. Release Candidate (RC) → freeze window → Prod (canary/blue-green).
• 6. Post-deploy тексеру және SLO/error budget бойынша автооткат.
• 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) Gates және дайындық критерийлері (Quality Gates)

Код және қауіпсіздік: линттер, жабын, SAST/SCA, тәуелділік саясаты, «critical/high» болмауы.
Келісімшарттар: схемалардың үйлесімділігі (API/оқиғалар), Pact/Buf тексеру.
Тесттер: unit/integration/e2e p-өту шегі, тұрақтылық (flake-rate).
Жүктеме smoke: p95/p99 бюджет шеңберінде, деградация жоқ.
DAST/IAST: сыни findings жоқ, сезімтал жолдар үшін пен-тест сценарийлер.
Observability: «as code» дашбордтары/алерттері жаңартылған, runbooks қолданылған.
CAB/UAT: шығару терезелерінде растау (егер реттеуіш/бизнес талап етсе).

5) Релиздік стратегиялар

Feature Flags - redeploy жоқ сызықты логикалық қосу; «dark launch» және A/B мүмкіндігі

Canary - трафик үлесінің біртіндеп ұлғаюы (5% → 25% → 50% → 100%), SLO және аномалиялар бойынша автоматты roll-forward/rollback.
Blue-Green - параллель орта; жылдам қосқыш, қарапайым кері қайтару.
Shadow/Traffic Mirroring - пайдаланушыларға әсер етпейтін жаңа нұсқаға трафикті пассивті айдап өту.
Ring Deployments - өңірлер/тенанттар бойынша толқындар.

6) Кері шегіністер және релиздердің қауіпсіздік саясаты

Триггерлер бойынша автооткат: биіктігі error-rate, табалдырықтан жоғары p95/TTFB, биіктігі 5xx/timeout, DLQ секірісі.
Қолмен кері қайту: '/rollback <service> <sha> 'командасы чат-ботта, релиз-консолдың бір батырмасы.
Freeze windows: сыни оқиғаларды (турнирлер/ең жоғары матчтар) шығаруға тыйым салынған.
Changelog & Release Notes: PR генерациясы, SemVer тегтері, компоненттер, миграциялар.

7) ДБ көші-қоны және үйлесімділігі

1. үйлесімді өрістерді/индекстерді қосу;

2. қосымшаны (екі схемада да оқиды/жазады);

3. деректердің фондық джобтармен көші-қоны;

4. ескісін жою.

Схемалар нұсқаланады, көшу idempotent, dry-run staging.

Protect destructive SQL: require flag/approval, автоматты бэкаптар және plan-check.

8) Фичефлагтар және үдемелі белсендіру

ops жалауларын (қауіпсіз пайдалану үшін) және product жалауларын бөліңіз.
Аудитория бойынша қосу: пайыз, гео, тенант, рөлі.
Жалау өлшемдері: конверсияға әсер ету, latency, қателер.
Проблемалар кезінде - жалауды жылдам орау.

9) Шығарылымның бір бөлігі ретінде Observability

Трестер: өтпелі 'trace _ id' gatewayден ДБ/кезекке дейін; ескі/жаңа нұсқаларын салыстыру.
Метриктер: p50/p95/p99, error-rate, RPS, saturation, DLQ, ретра, Time-to-Wallet/Business KPI.
Логтар: құрылымдалған, PII бүркемелеу, 'request _ id' корреляциясы.
Алерттар: SLO-бюджет, on-call жедел беттері, релизді авто-орау.

10) Жеткізу тізбегінің қауіпсіздігі (supply chain)

Әрбір билдке SBOM, сақтау және релиз тегіне байланыстыру.
Кескін қолтаңбалары (cosign), кластерде тексеру (policy admission).
SLSA-аттестаттау: артефактінің дәлелденетін шығу тегі.
Policy-as-Code (OPA/Conftest): инфрақұрылымдық PR үшін deny-by-default.
Құпиялар: тек KMS, қысқа өмір сүретін токендер, пайплайндардағы ротациялар.

11) Өзгерістерді бақылау және процестер

RFC → CRQ → CAB: мінез-құлықтың/келісімшарттардың құжатталған ауысуын алдын ала келісеміз.
Release Calendar: өнімдер/аймақтар/командалар бойынша көрінетін терезелер.
Runbooks: әрбір компонент үшін - қосу/қайтару/диагностикалау рәсімдері.
Postmortem/Retro: маңызды релиздерден кейін - талдау және әрекеттер.

12) Staging тестілеу профильдері

Келісімшарттық (API/Events): үйлеспейтін өзгерістерді бұғаттайды.
Интеграциялық/е2е: «депозит», «KYC», «шығару» жалғаспалы сценарийлері.
Жүктеме smoke: репрезентативті шыңдар; ресурстық лимиттерді қадағалаймыз.
Хаос сценарийлері: провайдерді ажырату, жасырындылықтың өсуі, желілік флаппингтер.
Синтетикалық мониторинг: кесте бойынша «сынама» транзакциялар.

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) Рөлдер мен жауапкершілік

Dev/Team: код сапасы, тесттер, көші-қон, runbooks.
QA: UAT/regression сценарийлері, gates-те сапаны бақылау.
SRE/Платформа: пайплайн сенімділігі, бақылау, саясат.
Release Manager: күнтізбе, терезелер, CAB, соңғы шешім.
Security: SAST/DAST/SCA, supply-chain, құпия саясаты.

15) Релиздердің жетілу моделі

1. Базалық - қолмен тексеру, сирек релиздер, кері қайту қиын.
2. Жетілдірілген - стандартталған CI/CD, staging-контур, canary/blue-green, жиі релиздер.
3. Сарапшылық - тенанттар/өңірлер бойынша прогрессивті жеткізу, feature flags-first, policy-as-code, SLO бойынша автооткат, толық трассалану және SLSA.

16) Енгізу жол картасы

M0-M1 (MVP): пайплайн үлгісі, build + sign + SBOM, staging-deploy, базалық тесттер және gates.
M2-M3: canary/blue-green, алдын ала per-PR, келісімшарт-тесттер, DAST, synthetic checks.
M4-M6: feature flags платформа, shadow traffic, policy-as-code, автооткат, release calendar + CAB-workflow.
M6 +: өңірлер бойынша ring-deployments, SLSA-аттестаттау және қатаң admission, runbooks толық автоматтандыру.

17) Өнертабыс алдындағы чек-парағы

• Суретке қол қойылды, SBOM жүктелді және релизге байланыстырылды.
• Келісімшарттар үйлесімді, тесттер жасыл, e2e staging өтті.
• Көші-қон тексерілді (dry-run), бэкап дайын, қайтару жоспары сипатталған.
• Дашбордтар/алерталар жаңартылды, SLO-гейттер белсенді.
• Runbook және Changelog жарияланған, шығару терезелер келісілген.
• Feature flags прогрессивті белсендіруге теңшелген.
• Freeze-шектеулер сақталды, on-call дайын.

Қысқаша қорытынды

Сауатты жобаланған staging-paypline релиздерді басқарылатын тәртіпке айналдырады: бірыңғай шаблондар, айқын quality gates, қорғалған жеткізу тізбегі, прогрессивті домалақтау және байқау қауіптерді азайтады және сапа мен бизнес-өлшемдерді бақылауды сақтай отырып, өнімге өзгерістерді шығару уақытын қысқартады.