Staging piplines და გამოშვებები

1) რატომ გჭირდებათ staging-pline

• შეკრებისა და გამოშვების რეპროდუქცია;
• სწრაფი და პროგნოზირებადი ფიტბეკი;
• რისკის შემცირება (პროგრესული მონაცვლეობა, ძაფები, გამოტოვება);
• შესაბამისობა და ცვლილებების კონტროლი.

2) სტანდარტული მიწოდების ნაკადი (მაღალი დონის)

1. PR - ავტომატური შემოწმება (ხაზოვანი, ერთეული, 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, დამოკიდებულების პოლიტიკა, „კრიტიკული/მაღალი“ არარსებობა.
კონტრაქტები: სქემების თავსებადობა (API/მოვლენები), Pact/Buf შემოწმება.
ტესტები: unit/integration/e2e გავლის ბარიერი, სტაბილურობა (სტაბილურობა).
დატვირთვა smoke: ბიუჯეტის ფარგლებში p95/p99, არ არსებობს დეგრადაცია.
DAST/IAST: არ არსებობს კრიტიკული ფაქტები, კალმის ტესტი მგრძნობიარე გზებისთვის.
Observability: დაშბორდები/ალერტები „as code“ განახლებულია, runbooks ერთვის.
CAB/UAT: დადასტურება გამოშვების ფანჯრებში (თუ საჭიროა მარეგულირებელი/ბიზნესი).

5) გამოშვებული სტრატეგიები

Feature Flags - ლოგიკური ჩართვა ფრჩხილების გარეშე; „dark launch“ და A/B. შესაძლებლობა

Canary არის ტრაფიკის წილის თანდათანობითი მატება (5% - 25% - 50% - 100%), ავტომატური roll-forward/rollback თითო SLO და ანომალიები.
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 დროშები (უსაფრთხო ოპერაციისთვის) და წარმოების დროშები.
აუდიტორიის ჩართვა: პროცენტი, გეო, ტენანტი, როლი.
დროშის მეტრიკა: გავლენა კონვერტაციაზე, ლატენტობაზე, შეცდომებზე.
პრობლემებით - დროშის პაკეტი უფრო სწრაფია, ვიდრე დაბრუნება.

9) Observability, როგორც გამოშვების ნაწილი

ტრეისი: 'trace _ id' გავლით gateway- დან BD/რიგებამდე; ძველი/ახალი ვერსიის შედარება.
მეტრიკა: p50/p95/p99, error-rate, RPS, saturation, DLQ, retrai, Time-to-Wallet/Business KPI.
ლოგოები: სტრუქტურირებული, შენიღბვა PII, კორელაცია 'request _ id'.
ალერტები: SLO ბიუჯეტი, გადაუდებელი გვერდები on-call, მანქანების პაკეტი.

10) მიწოდების ჯაჭვის უსაფრთხოება

SBOM თითოეული ბილეთის, შენახვისა და გამოშვების ჭდისთვის.
სურათების ხელმოწერა, შემოწმება კლასტერზე (პოლიცია).
SLSA სერტიფიკაცია: არტეფაქტის დადასტურებული წარმოშობა.
Policy-as-Code (OPA/Conftest): deny-by-default ინფრასტრუქტურული PR.
საიდუმლოებები: მხოლოდ KMS- დან, მოკლემეტრაჟიანი ნიშნებიდან, როტაციებში.

11) ცვლილებებისა და პროცესების კონტროლი

RFC - CRQ - CAB: ჩვენ წინასწარ ვთანამშრომლობთ ქცევების/კონტრაქტების დოკუმენტურ ცვლილებაზე.
Release Calendar: ხილული ფანჯრები პროდუქტებზე/რეგიონებში/გუნდებზე.
Runbooks: თითოეული კომპონენტისთვის - ჩართვის/გამოტოვების/დიაგნოზის პროცედურები.
Postmortem/Retro: მნიშვნელოვანი გამოშვების შემდეგ - ანალიზი და მოქმედებები.

12) ტესტის პროფილები

კონტრაქტი (API/Events): ბლოკავს შეუთავსებელ ცვლილებებს.
ინტეგრაცია/e2e: სცენარი „ანაბარი“, „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 სკრიპტები, ხარისხის კონტროლი გეტებზე.
SRE/პლატფორმა: paylines- ის საიმედოობა, დაკვირვება, პოლიტიკა.
Release მენეჯერი: კალენდარი, ფანჯრები, CAB, საბოლოო გამოსავალი.
უსაფრთხოება: 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): paypline შაბლონი, build + sign + SBOM, staging deple, ძირითადი ტესტები და gates.
M2-M3: canary/blue-green, აღემატება per-PR, კონტრაქტის ტესტები, DAST, სინთეზური შემოწმებები.
M4-M6: feature flags პლატფორმა, shadow traffic, policy-as-code, ავტოტრანსპორტი, release calendar + CAB-workflow.
M6 +: რეგიონების გამანადგურებლები, SLSA სერტიფიკაცია და მკაცრი admission, runbooks- ის სრული ავტომატიზაცია.

17) ჩეკის სია პროდ-გამოშვებამდე

• ხელი მოეწერა სურათს, SBOM დატვირთულია და მიბმული გამოშვებასთან.
• კონტრაქტები თავსებადია, ტესტები მწვანეა, e2e წავიდა შეტევაზე.
• მიგრაცია შემოწმებულია (dry-run), becap მზად არის, დაბრუნების გეგმა აღწერილია.
• დაშბორდები/ალერტები განახლებულია, SLO კარიბჭეები აქტიურია.
• Runbook და Changelog გამოქვეყნებულია, გამოშვების ფანჯრები შეთანხმებულია.
• Feature flags შექმნილია პროგრესული გააქტიურებისთვის.
• შეინიშნება უფასო შეზღუდვები, მზად არის.

მოკლე დასკვნა

კომპეტენტურად შემუშავებული staging-pipline გამოშვებებს გადააქცევს კონტროლირებად რუტინად: ერთიანი შაბლონები, მკაფიო quality gates, დაცული მიწოდების ჯაჭვი, პროგრესული ჩამოსხმა და დაკვირვება ამცირებს რისკს და ამცირებს წარმოების პროდუქტებში ცვლილებების შეტანის დროს, ინარჩუნებს კონტროლს ხარისხზე და ბიზნეს მეტრიკებზე.