شیوه های DevOps و CI/CD
1) اهداف و اصول
سریع و ایمن: چرخه های کوتاه، دسته های کوچک تغییرات، چک های خودکار.
تکرارپذیری: زیرساخت به عنوان کد (IaC)، محیط = کد + سیاست.
قابلیت مشاهده: معیارهای/دنباله/سیاهههای مربوط از جعبه، SLO به عنوان یک قرارداد.
انطباق: ممیزی، کنترل تغییر، جداسازی داده های منطقه ای.
قانون طلایی: کیفیت اول، سپس سرعت، در غیر این صورت سرعت هرگز ظاهر نخواهد شد.
2) شاخه ها و محیط ها
پرچم های ویژگی Trunk-based + - انتخاب اساسی.
خطوط ویژگی کوتاه (≤ 2-5 روز)، ادغام روزانه در تنه.
پرچم های سمت سرور برای تحویل افزایشی و بازپرداخت امن.
محیط گیت: 'dev' → 'stage' → 'prod' (+ regional 'prod-eu', 'prod-latam').
ارتقاء مصنوعات: یک تصویر جمع آوری شده از طریق رسانه ها ترویج می شود (برچسب تغییر ناپذیر توسط هضم).
هنگامی که GitFlow: انتشار نادر مجامع نظارتی/SDK ها - سپس شاخه ها + «سخت شدن» را آزاد کنید.
3) هرم کیفیت و «خط قرمز»
1. تجزیه و تحلیل استاتیک (SAST، لاینرها، مجوزها).
2. تست های مبتنی بر واحد/املاک (ثانیه).
3. تست قرارداد (CDC) برای API ها و رویدادها (OpenAPI/AsyncAPI، Schema Registry).
4. ادغام (Testcontainers، کارگزاران محلی).
5. E2E مسیر بحرانی: ثبت نام → KYC → سپرده → راه اندازی بازی → خروجی
6. تست بار/هرج و مرج برای پرداخت/کیف پول/ارائه دهندگان بازی.
کیفیت عبور نمی کند → سپرده مسدود شده است. هیچ «استثنا دستی» بدون تغییر رکورد وجود دارد.
4) زنجیره تامین
SBOM برای هر تصویر/بسته (CycloneDX/SPDX).
امضای مصنوعی (cosign)، سیاست «فقط امضا شده» در پذیرش.
SCA/Dependabot: آسیب پذیری ها و مجوزها
منبع/SLSA: مجامع تجدید پذیر، عامل ساخت بسته، گواهینامه ها.
رازها: در مدیر (KMS/External Secrets)، حتی یک راز هم در انبار نیست.
5) GitOps и IaC
Infra به عنوان کد: Terraform/Pulumi برای ابر ؛ هلم/Kustomize برای k8s.
کنترل کننده GitOps (ArgoCD/Flux): مانیفست های اعلام شده، بررسی PR، دنباله حسابرسی.
ویندوز/یخ: مسابقات هفته/ساعت اوج - خودکار مکث از انتشار تولید.
سیاستهای OPA/Kyverno: no ': latest', non-root, read-only FS, hostPath disallow.
6) تحویل مترقی
Canary: 1 → 5 → 25 → 50 → 100٪ در معیارهای guardrail (تاخیر p95، 5xx، سوزاندن بودجه خطا).
آبی سبز: سوئیچ سریع + طرح برگشت.
سایه/آینه: کپی درخواست بدون تاثیر پاسخ (برای آداپتورهای PSP جدید).
پرچم های ویژگی: شامل بخش (منطقه/نقش/شریک/کانال) + kill-switch.
7) مهاجرت پایگاه داده (گسترش و قرارداد)
مرحله 1: طرح را گسترش دهید (ستون های جدید/شاخص ها) - سازگار با کد قدیمی.
مرحله 2: تخلیه کد که به هر دو نسخه/زمینه می نویسد.
مرحله 3: پس زمینه مهاجرت داده ها joba، معیارهای پیشرفت.
مرحله ۴: خواندن را به فیلدهای جدید تغییر دهید.
مرحله 5: حذف قدیمی یک نسخه جداگانه است.
مسدود کردن ممنوعیت DDL در زمان نخست ؛ برای جداول بالا - مهاجرت آنلاین.
8) قابلیت مشاهده و SLO
معیارهای: RPS، p50/95/99، 4xx/5xx، اشباع (CPU/mem/صف)، DLQ/کارگزار تاخیر.
معیارهای کسب و کار: TTP (زمان به بازی)، TtW (زمان به کیف پول)، موفقیت FTD، KYC-TtV.
ردیابی: شناسه ردیابی از دروازه به پایگاه داده.
SLO: به عنوان مثال، "واریز p95 ≤ 300-500 ms"، "موفقیت 98 ≥. 5٪، در دسترس بودن 99 ≥. 9%`.
هشدار میزان سوختگی + انتشار خودکار مکث در طول تخریب.
9) حوادث، پس از مرگ، تغییرات
Runbooks در جریان های بحرانی (سپرده/خروجی/ACC، بازی های زنده).
مقیاس اولویت: P1...P4، مالک، ETA، ارتباطات (بنر، صفحه وضعیت، شرکا).
پس از مرگ بی گناه با آیتم های عمل و تاریخ.
تغییرات در تماس، هشدار چت، به روز رسانی وضعیت هر N دقیقه.
دنباله اسکله: چه کسی/چه زمانی/چه چیزی ارسال شده (مرتکب، مصنوعات، محیط زیست، پرچم).
10) امنیت و انطباق (DevSecOps)
SAST/DAST/IAST، اسکن مخفی در CI.
mTLS servis↔servis، JWT با TTL کوچک، چرخش کلید.
ماسک PII/PAN در سیاهههای مربوط/آهنگ ؛ گزارش فعالیت مدیریت WORM.
Geo-segregation: خوشه ها/پایگاه های داده بر اساس منطقه، مسیریابی دروازه.
مدیریت تغییر: بلیط/تایید برای مناطق حساس (کیف پول/محدودیت).
11) معیارهای DORA و FinOps
فرکانس استقرار (روزانه نسخه های کوچک).
زمان سرب برای تغییرات (ایده آل: تماشا).
MTTR (بازیابی: دقیقه/ساعت).
نرخ شکست تغییر (≤ هدف 15٪).
FinOps: هزینه محیط، ذخیره RPS، استخرهای گرم، مکث خودکار کارگران، «هزینه هر معامله».
12) ویژگی iGaming
قله (مسابقات/زندگی می کنند): تغییرات عمده انجماد, گرم کردن کش/تصاویر, افزایش سهمیه.
پرداخت/کیف پول: استخر/گره های فردی، SLO های بالا، راه اندازی قناری توسط منطقه، تله متری دوگانه توسط ارائه دهندگان PSP.
CC/انطباق: آهنگ جداگانه از انتشار، پس از به روز رسانی اجباری از انطباق.
همکاران/وابستگان: SDK امن، نسخه API با پنجره پشتیبانی و نظارت بر مشتریان قدیمی.
13) مثال CI/CD (YAML، اقدامات GitHub → ArgoCD)
yaml name: ci-cd on:
push:
branches: [ main ]
paths: [ "services/wallet/" ]
jobs:
build_test_scan:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: Setup Node uses: actions/setup-node@v4 with: { node-version: 22 }
- run: npm ci --omit=dev working-directory: services/wallet
- run: npm test -- --ci working-directory: services/wallet
- name: Lint & SAST run: npm run lint && npm run sast working-directory: services/wallet
- name: Build image run:
docker build -t registry. local/wallet:${{ github. sha }} -f Dockerfile.
cosign sign --key $COSIGN_KEY registry. local/wallet:${{ github. sha }}
- name: SBOM & Scan run:
syft packages registry. local/wallet:${{ github. sha }} -o cyclonedx-json > sbom. json trivy image --exit-code 1 --severity HIGH,CRITICAL registry. local/wallet:${{ github. sha }}
- name: Push image run: docker push registry. local/wallet:${{ github. sha }}
deploy_stage:
needs: build_test_scan runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- name: Bump Helm values (image tag)
run: yq -i '.image. tag = "${{ github. sha }}"' helm/wallet/values-stage. yaml
- name: Create PR to gitops repo run: gh pr create -R org/gitops -B stage -H stage-bump/wallet-${{ github. sha }} -t "wallet:${{ github. sha }}" -b "Promote to stage"
promote_prod:
if: github. ref == 'refs/heads/main'
needs: deploy_stage runs-on: ubuntu-latest steps:
- name: Gate: SLO/quality checks run:./scripts/gates/check_stage_health. sh # p95, 5xx, e2e ok
- name: Canary 10%
run:./scripts/gitops/canary. sh wallet ${{ github. sha }} 10
- name: Auto-pause on degradation run:./scripts/gates/guardrails. sh./scripts/gitops/rollback. sh wallet
- name: Roll to 100%
run:./scripts/gitops/rollout. sh wallet ${{ github. sha }} 100
14) چک لیست
قبل از ادغام به اصلی
- واحد/CDC/ادغام سبز.
- خطوط/SAST/مجوز تمیز هستند.
- به روز رسانی طرح های OpenAPI/AsyncAPI و مهاجرت پایگاه داده.
- پرچم های fiche اضافه شده، follbacks تعریف شده است.
قبل از انتشار در انگیزه
- تصویر امضا شده، SBOM متصل شده، آسیب پذیری های HIGH/CRIT بسته شده است.
- داشبورد/هشدار ایجاد شده ؛ دروازه های SLO متصل می شوند.
- طرح برگشت، کشتن سوئیچ، سایه (در صورت لزوم).
- محدودیت های منطقه ای و سیاست داده تایید شده است.
حوادث
- Runbook یافت و به روز.
- ارتباط با کاربران/شرکا (قالب، ETA).
- Postmortem در 48 ساعت، آیتم های عمل با تاریخ.
15) ضد الگوهای
«مونتاژ مجدد برای هر محیط» (بدون ارتقاء مصنوعی).
مراحل استقرار دستی بدون ممیزی/تکرارپذیری.
مهاجرت پایگاه داده «سر»، پاسخ API ناسازگار.
اسرار در متغیرهای CI یا در مخزن.
ویژگی های فاجعه آمیز بدون پرچم/عقب نشینی.
فقدان SLO/guardrails در انتشار قناری.
سیاهههای مربوط با PII/PAN، بدون ماسک.
16) قالب های مفید میکرو کپی
انتشار (به همکاران):- "ما در حال بروزرسانی ماژول پرداخت در مراحل (10٪ → 100٪) هستیم. تاخیر ثبت نام کوتاه مدت تا 2 دقیقه امکان پذیر است. ETA تکمیل - 9 PM EET"
- "ارائه دهنده پرداخت X ناپایدار است. ثبت نام می تواند تا 15 دقیقه طول بکشد. ما در حال کار بر روی یک راه حل هستیم. به روز رسانی وضعیت بعدی در دقیقه 30 است"
- "به روز رسانی به دلیل افزایش تاخیر در انتظار است. نسخه قبلی را برمیگردانیم. داده ها و عملیات ذخیره شده اند"
17) فرآیند پیاده سازی (4 سرعت)
1. استانداردهای کیفیت و خط لوله: SAST/واحد/CDC، تصویر واحد، امضا، SBOM.
2. محیط GitOps +: Helm/Kustomize، ArgoCD، ارتقاء مصنوعات، سیاست مخفی.
3. نسخه های پیشرفته و دروازه های SLO: canary/shadow، guardrails، auto-hub.
4. قابلیت اطمینان و هزینه: آزمون هرج و مرج، استخر خودکار/گرم، داشبورد FinOps.
برگه تقلب نهایی
تنه + پرچم + دسته های کوچک = سرعت بدون استرس.
مصنوعات تک امضا + SBOM = زنجیره تامین کنترل شده.
GitOps + Policies = تکرارپذیری و حسابرسی.
دروازه های Canary/Blue-Green + SLO = نسخه های امن.
گسترش و قرارداد برای DB = خرابی صفر.
قابلیت مشاهده و DORA = بهبود قابل کنترل
انزوای منطقه ای و انطباق = مطابق با قوانین و اعتماد.