WisarWisar
Dasturlash kitobi/10-QISM — DevOps44 daqiqa

10.5-bob: CI/CD — GitHub Actions

10-QISM — DevOps va Deploy · 5-mavzu


1. Kirish va motivatsiya

Shu paytgacha 10-QISM'da kodni serverga qo'lda chiqarishni o'rgandik: SSH bilan ulanamiz 10.1-bob, rsync bilan fayllarni yuboramiz (10.1: 2.11), systemctl restart qilamiz (10.1: 2.6), yoki Docker image qurib docker push qilamiz (10.3, 10.4). Bu — qo'lda deploy (manual deployment). Bir-ikki marta ishlaydi, lekin tezda muammoga aylanadi: har deploy oldidan testni qo'lda ishga tushirishni unutasiz; lint xatosi bilan kod production'ga chiqadi; ikki dasturchi bir vaqtda deploy qilib bir-birini "ezadi"; "menda ishlayapti-ku" deb chiqarib, serverda yiqiladi. Qo'lda jarayon — sekin, xatoga moyil va takrorlanmaydigan.

Yechim — CI/CD: jarayonni avtomatlashtirish. Har push'da kod o'z-o'zidan tekshiriladi, test qilinadi, qurib (build) chiqariladi va serverga chiqariladi — odam aralashuvisiz. Ikki atama: CI (Continuous Integration — uzluksiz integratsiya) — har bir o'zgarishni avtomatik birlashtirib tekshirish: lint, test, build har push'da ishlaydi, xato darrov topiladi (PR merge bo'lishidan oldin — 4.3). CD ikki ma'noga ega: Continuous Delivery (uzluksiz yetkazib berish) — har o'zgarish chiqarishga tayyor holatga keladi, lekin production'ga chiqarish bitta tugma/tasdiqdan keyin; Continuous Deployment (uzluksiz joylashtirish) — har o'tgan test'dan keyin avtomatik production'ga chiqadi (qo'lda tasdiq yo'q). 2026'da bu — standart amaliyot, "yaxshi" emas, majburiy. GitHub Actions — GitHub'ning o'ziga qurilgan CI/CD platformasi (alohida server kerak emas, repozitoriyangda ishlaydi).

Bu bob: CI vs CD farqi, GitHub Actions arxitekturasi (workflow/job/step/runner/action), workflow YAML anatomiyasi (.github/workflows/*.yml), trigger event'lar (push/pull_request/schedule/manual), runner (GitHub-hosted vs self-hosted), job'lar (parallel va sequential — needs), matrix build (ko'p Node versiya/OS), action'lar (marketplace, uses, with, versiya), secrets va xavfsizlik (GITHUB_TOKEN, repo secrets, OIDC), caching (tezlik), artifact (build natijasi), environment va approval, tipik pipeline bosqichlari (linttestbuilddockerdeploy) va deploy strategiyalari (SSH, Docker registry, rsync). Bu bob 10.1 (SSH deploy), 10.3/10.4 (Docker), 8.11 (test), 4.3 (Git/PR) ni bir avtomatik konveyerga bog'laydi.

O'xshatish: CI/CD — avtomatlashtirilgan zavod konveyer liniyasi. Ilgari mahsulotni (kodni) bir usta qo'lda yig'ar, qo'lda tekshirar, qo'lda qadoqlab jo'natardi — sekin va har safar boshqacha (xato bo'lardi). Endi konveyer qo'yilgan: detal (commit) tasmaga tushadi birinchi stansiya sifat nazorati (lint — qoidaga mosmi), keyin sinov stansiyasi (test — ishlaydimi), keyin yig'ish stansiyasi (build — qadoqlash), oxirida jo'natish (deploy — mashinaga ortib do'konga — serverga). Har stansiyada xato topilsa — konveyer to'xtaydi, signal beradi (qizil belgi, email), nuqsonli mahsulot keyingi bosqichga o'tmaydi. Runner — konveyerda ishlaydigan robot-ishchi (GitHub ijaraga beradi). Workflow — butun konveyer chizmasi (.yml faylda yozilgan). Action — tayyor stansiya bloki (boshqalar yasagan, siz ulab ishlatasiz). Secret — seyfdagi kalit (deploy paroli — chizmada ko'rinmaydi, lekin robot ishlatadi). Konveyer bir marta sozlanadi, keyin har detal uchun bir xil, aniq, tez ishlaydi.

Nega muhim?

  • Sifat — har push'da test/lint avtomatik (buzuq kod production'ga chiqmaydi — CI).
  • Tezlik — deploy bir necha daqiqada, qo'lsiz (odam kutmaydi).
  • Ishonchlilik — jarayon takrorlanadigan (har safar bir xil — "menda ishlayapti" yo'qoladi).
  • Hamkorlik — PR'da yashil/qizil belgi 4.3-bob; buzuq kod merge bo'lmaydi (branch protection).
  • Intervyu/ish — "CI/CD sozlaganmisan?" — har backend/DevOps suhbatining savoli.

2. Nazariya — chuqur tushuntirish

2.1. CI vs Continuous Delivery vs Continuous Deployment

text
  UCH ATAMA (ko'pincha aralashtiriladi):

  CI — Continuous Integration (uzluksiz integratsiya):
   har push/PR'da kod AVTOMATIK birlashtirilib tekshiriladi
   lint + test + build (xato darrov topiladi, kichik bo'lakda)
   maqsad: "main" doim ishlaydigan holatda (broken bo'lmasin)

  CD (1) — Continuous Delivery (uzluksiz YETKAZIB BERISH):
   CI o'tgach, kod CHIQARISHGA TAYYOR holatga keladi (artifact/image)
   production'ga chiqarish — QO'LDA tugma/tasdiq bilan (odam bosadi)

  CD (2) — Continuous Deployment (uzluksiz JOYLASHTIRISH):
   CI o'tgach, AVTOMATIK production'ga chiqadi (qo'lda tasdiq YO'Q)
   eng yuqori avtomatlashtirish (kuchli test ishonchi kerak)

  ┌──────┐   ┌──────┐   ┌───────┐   ┌──────────┐   ┌─────────┐
  │ push │  │ lint │  │ test  │  │  build   │  │ deploy  │
  └──────┘   └──────┘   └───────┘   └──────────┘   └─────────┘
             └──────── CI ─────────┘ └──── CD ─────┘

CI/CD — uch atama (aralashtirmaslik kerak): CI (Continuous Integration) — har push/PR'da kod avtomatik tekshiriladi (lint, test, build), maqsad — main doim ishlaydigan holatda. CD ikki ma'no: Continuous Delivery — CI o'tgach kod chiqarishga tayyor bo'ladi, lekin production'ga chiqarish qo'lda tasdiq bilan (odam tugma bosadi — nazorat saqlanadi); Continuous Deployment — test o'tgach avtomatik production'ga chiqadi (qo'lda tasdiq yo'q — eng tez, lekin test'ga to'liq ishonch kerak). Amaliy farq: Delivery = "tayyor, lekin odam chiqaradi"; Deployment = "o'zi chiqadi". Ko'p jamoa Deliverydan boshlaydi (production'ga avtomatik chiqishdan qo'rqadi), keyin ishonch ortgach Deploymentga o'tadi. Ikkalasi ham CIga tayanadi (test'siz CD — xavfli).

2.2. GitHub Actions arxitekturasi (workflow job step)

text
  GITHUB ACTIONS — GitHub ichidagi CI/CD (alohida server kerak emas):

  EVENT (hodisa)           push, pull_request, schedule, manual
     │  ishga tushiradi
     ▼
  WORKFLOW (.github/workflows/ci.yml)    butun jarayon (YAML fayl)
     ├── JOB: test         bir RUNNER'da ishlaydi (alohida mashina)
     │    ├── STEP 1: checkout (kodni ol)
     │    ├── STEP 2: setup-node (Node o'rnat)
     │    ├── STEP 3: npm ci (paket o'rnat)
     │    └── STEP 4: npm test (test)
     └── JOB: deploy       boshqa RUNNER (needs: test — test o'tgach)
          └── STEP: serverga chiqar

  TUSHUNCHALAR:
  - WORKFLOW: butun avtomatik jarayon (bir .yml fayl)
  - JOB: mustaqil ishlar to'plami (bir runner'da, default — parallel)
  - STEP: bitta qadam (buyruq yoki action)
  - RUNNER: ishni bajaradigan virtual mashina (GitHub beradi)
  - ACTION: qayta ishlatiladigan tayyor blok (uses bilan ulanadi)

GitHub Actions arxitekturasi — to'rt pog'ona: (1) Event (hodisa) — workflow'ni ishga tushiruvchi (push, PR, vaqt jadvali, qo'lda tugma); (2) Workflow — butun avtomatik jarayon, .github/workflows/<nom>.yml faylda yoziladi (bir repo'da bir nechta bo'lishi mumkin — ci.yml, deploy.yml); (3) Job — mustaqil ishlar to'plami, bir runner'da ishlaydi, default'da boshqa job'lar bilan parallel 2.6-bob; (4) Step — bitta qadam (shell buyruq yoki tayyor action). Har bir job — toza, yangi virtual mashina (oldingi job'dan hech narsa qolmaydi — fayllar needs/artifact orqali uzatiladi). Runner — ishni bajaradigan mashina (GitHub ijaraga beradi — 2.4). Action — qayta ishlatiladigan blok (actions/checkout — kod olish; boshqalar yozgan — siz uses bilan ulaysiz — 2.7). Bu ierarxiyani tushunish — barcha workflow yozishning asosi.

2.3. Workflow YAML anatomiyasi (.github/workflows/*.yml)

text
  WORKFLOW FAYLI — .github/workflows/ ichida (.yml/.yaml):

  name: CI                           workflow nomi (UI'da ko'rinadi — ixtiyoriy)

  on:                                QACHON ishga tushadi (trigger — 2.5)
    push:
      branches: [main]               faqat main'ga push'da

  jobs:                              ishlar (kamida bitta)
    test:                            job ID (ixtiyoriy nom)
      runs-on: ubuntu-latest         qaysi runner 2.4-bob
      steps:                         qadamlar (ketma-ket)
        - uses: actions/checkout@v4  action ishlatish (uses — 2.7)
        - name: Testlarni ishga tushir    qadam nomi (ixtiyoriy)
          run: |                     shell buyruq (run)
            npm ci
            npm test

   YAML — bo'sh joy (indent) MUHIM (tab YO'Q — faqat probel, 2 ta)
   "-"  ro'yxat elementi (step) ;  "key:"  kalit-qiymat

Workflow YAML anatomiyasi — fayl .github/workflows/ papkasida (.yml yoki .yaml). Asosiy kalitlar: name — workflow nomi (UI'da ko'rinadi, ixtiyoriy); onqachon ishga tushadi (trigger event — 2.5); jobs — ishlar (kamida bitta); har job ichida runs-on (qaysi runner — 2.4) va steps (qadamlar). Step ikki xil: uses (tayyor action — 2.7) yoki run (shell buyruq — | bilan ko'p qatorli). Qadamga name berish mumkin (UI'da o'qiladi). YAML qoidasi: bo'sh joy (indent) — ma'noli, tab ishlatma (faqat probel, odatda 2 ta); - — ro'yxat elementi (har step bitta -), key: — kalit-qiymat. Indent xatosi — eng keng tarqalgan xato (2.6 Xato 5). Repo'da .yml fayl paydo bo'lishi bilan GitHub uni avtomatik o'qiydi va "Actions" tab'ida ishga tushiradi.

2.4. Runner — GitHub-hosted vs self-hosted

text
  RUNNER — workflow'ni bajaradigan mashina (job shu yerda ishlaydi):

  GITHUB-HOSTED (GitHub beradi — eng oson):
  runs-on: ubuntu-latest       Linux (eng keng, tez, arzon)
  runs-on: windows-latest      Windows
  runs-on: macos-latest        macOS (qimmatroq — iOS build uchun)
   Har job uchun TOZA, yangi mashina (izolyatsiya)
   Sozlash kerak emas (Node, Docker, git oldindan bor)
   Public repo — BEPUL; private — oylik daqiqa limiti

  SELF-HOSTED (o'zingning mashinang):
  runs-on: self-hosted         o'z serveringda runner agent ishlaydi
   Kuchli/maxsus apparat (GPU, ko'p RAM)
   Ichki tarmoqqa kirish (private resurs)
   O'zing boqasan (yangilash, xavfsizlik — public repo'da XAVFLI)

   Boshlash uchun: ubuntu-latest (99% holatda yetarli)

Runner — workflow job'ini bajaradigan mashina. Ikki tur: GitHub-hosted (GitHub beradigan virtual mashina — runs-on: ubuntu-latest eng keng, tez, arzon; windows-latest, macos-latest ham bor). Har job uchun toza, yangi mashina (izolyatsiya — bir job ikkinchisiga ta'sir qilmaydi), Node/Docker/git oldindan o'rnatilgan, sozlash kerak emas. Public repo'da bepul, private'da oylik daqiqa limiti bor (keyin to'lov). Self-hosted — o'zingning serveringda runner agent ishlatasiz (runs-on: self-hosted): kuchli/maxsus apparat (GPU), ichki tarmoqqa kirish kerak bo'lganda; lekin xavfsizligini o'zingiz ta'minlaysiz (public repo'da self-hosted — xavfli, begona kod sizning mashinangda ishlashi mumkin). Boshlash uchun ubuntu-latest — 99% holatda yetarli (Linux serverga deploy ham Linux runner'da mantiqiy — 10.1).

2.5. Trigger event'lar (push / pull_request / schedule / manual)

text
  ON — workflow QACHON ishga tushadi (trigger event):

  on:
    push:                         push bo'lganda
      branches: [main, dev]       faqat shu branch'larga
      paths: ["src/**"]           faqat shu fayllar o'zgarsa (ixtiyoriy)
      tags: ["v*"]                teg push'da (release)

    pull_request:                 PR ochilganda/yangilanganda 4.3-bob
      branches: [main]            main'ga qaratilgan PR

    schedule:                     vaqt jadvali (cron)
      - cron: "0 3 * * *"         har kuni 03:00 UTC (kechasi test)

    workflow_dispatch:            QO'LDA tugma (UI'dan ishga tushirish)
      inputs:                     (ixtiyoriy) kiruvchi qiymatlar
        environment:
          type: choice
          options: [staging, production]

   pull_request — fork'dan kelgan PR'da SECRET berilmaydi (xavfsizlik)
   cron — UTC vaqtida (mahalliy vaqt EMAS)

Trigger event'lar (on:) — workflow qachon ishga tushadi: push — kod push bo'lganda (branches bilan faqat ma'lum branch'larga; paths bilan faqat ma'lum fayllar o'zgarsa; tags bilan teg push'ida — release uchun); pull_request — PR ochilganda/yangilanganda (CI uchun eng muhim — kod merge bo'lishidan oldin tekshiriladi — 4.3); schedule — vaqt jadvali (cron sintaksisi, masalan "0 3 * * *" — har kuni 03:00 UTC'da — kechasi to'liq test); workflow_dispatchqo'lda ishga tushirish (GitHub UI'da "Run workflow" tugmasi, ixtiyoriy inputs bilan — masalan qaysi muhitga deploy qilish). Ikki muhim nuqta: (1) fork'dan kelgan PR'da secret'lar berilmaydi (begona kod paroliga yetmasin — xavfsizlik); (2) cron doim UTC vaqtida (mahalliy vaqt emas — Toshkent UTC+5). Bir workflow bir nechta event'ga javob berishi mumkin.

2.6. Job'lar — parallel va sequential (needs)

text
  JOB'LAR — default PARALLEL (bir vaqtda), needs bilan SEQUENTIAL:

  jobs:
    lint:                    ┐
      runs-on: ubuntu-latest │ lint va test PARALLEL
    test:                    │ (bir vaqtda — tez)
      runs-on: ubuntu-latest ┘

    deploy:
      needs: [lint, test]     lint VA test o'tgach (sequential)
      runs-on: ubuntu-latest │ ikkalasi muvaffaqiyatli bo'lsa

  ┌──────┐
  │ lint │──┐
  └──────┘  │   ┌────────┐
            ├──▶│ deploy │    needs: ikkalasini KUTADI
  ┌──────┐  │   └────────┘
  │ test │──┘
  └──────┘

   Har job TOZA mashina (deploy lint'ning fayllarini KO'RMAYDI)
   fayl kerak bo'lsa: artifact (upload/download — 2.9)
   needs'dagi job FAIL bo'lsa  keyingi job ISHLAMAYDI (to'xtaydi)

Job'lar — default'da parallel (bir vaqtda — tezlik uchun): lint va test bir-birini kutmay ishga tushadi. Sequential (ketma-ket) qilish uchun needs: deploy: needs: [lint, test]deploy faqat lint va test muvaffaqiyatli o'tgach ishlaydi (ikkalasi fail bo'lsa — deploy ishlamaydi, butun pipeline qizil). Bu — bog'liqlik grafi (dependency graph): GitHub qaysi job qaysidan keyin kelishini needs'dan tushunadi. Eng muhim tushuncha: har job — toza, alohida mashina 2.2-bob. deploy job'i test job'i qurgan fayllarni ko'rmaydi (boshqa mashinada edi). Fayl uzatish kerak bo'lsa — artifact (upload-artifact/download-artifact — 2.9). Bu — boshlovchilar tez-tez qoqiladigan joy ("build qildim, lekin deploy job'da dist/ yo'q"). Job'lar grafi — pipeline'ning skeleti.

2.7. Action'lar — marketplace, uses, with, versiya

text
  ACTION — qayta ishlatiladigan tayyor blok (boshqalar yozgan):

  steps:
    - uses: actions/checkout@v4          rasmiy action (kodni oladi)
                  │        │   │
                  │        │   └─ VERSIYA (@v4 — har doim qadab qo'y!)
                  │        └─ action nomi
                  └─ ega (org/user yoki "actions" — GitHub rasmiy)

    - uses: actions/setup-node@v4        Node o'rnatadi
      with:                              action'ga PARAMETR berish
        node-version: "20"
        cache: "npm"

  ENG KENG ISHLATILADIGAN ACTION'LAR (2026):
  actions/checkout@v4           repo kodini runner'ga oladi (ENG BIRINCHI)
  actions/setup-node@v4         Node.js + npm cache
  actions/cache@v4              ixtiyoriy fayllarni keshlash 2.8-bob
  actions/upload-artifact@v4    build natijasini saqlash 2.9-bob
  docker/build-push-action@v6   Docker image qurish+push 10.3-bob
  appleboy/ssh-action@v1        SSH orqali serverda buyruq (10.1)

   Versiyani QADA (@v4) — @main XAVFLI (har o'zgarishda buzilishi mumkin)

Action — qayta ishlatiladigan tayyor blok (boshqa dasturchilar/GitHub yozgan, Marketplace'da topiladi). uses bilan ulanadi: actions/checkout@v4actions (ega — GitHub rasmiy), checkout (nom), @v4 (versiya). Action'ga parametr — with bloki (masalan setup-node'ga node-version, cache). Eng keng ishlatiladigan (2026): actions/checkout@v4 (repo kodini runner'ga oladi — har workflow'ning birinchi qadami, bu bo'lmasa kod yo'q); actions/setup-node@v4 (Node + npm cache); actions/cache@v4 (keshlash — 2.8); actions/upload-artifact@v4 (artifact — 2.9); docker/build-push-action@v6 (Docker — 10.3); appleboy/ssh-action (SSH deploy — 10.1). Versiyani har doim qada (@v4) — @main ishlatma (action o'zgarganda workflow'ing kutilmaganda buziladi, yoki xavfsizlik xavfi). Eng xavfsizi — versiyani aniq commit SHA'ga qadash (supply-chain hujumlardan himoya).

2.8. Secrets va xavfsizlik (GITHUB_TOKEN, repo secrets, OIDC)

text
  SECRET — maxfiy qiymat (parol, kalit, token) — kodga YOZILMAYDI:

  REPO SECRETS (Settings  Secrets and variables  Actions):
   SSH_PRIVATE_KEY, DB_PASSWORD, API_TOKEN... (UI'da kiritiladi)
   workflow'da: ${{ secrets.SSH_PRIVATE_KEY }}
   log'da AVTOMATIK yashiriladi (*** ko'rinadi — chiqsa ham)

  GITHUB_TOKEN — har run'da AVTOMATIK beriladi (alohida yaratmaysan):
   repo'ga cheklangan huquq (push, GHCR'ga image — 10.4)
   ${{ secrets.GITHUB_TOKEN }}
   permissions bilan huquqni cheklash (eng kam imtiyoz — 10.1: 2.4):
  permissions:
    contents: read
    packages: write           GHCR'ga push uchun

  OIDC (OpenID Connect) — SECRET'SIZ bulutga kirish (eng zamonaviy):
   uzoq muddatli AWS kalit saqlamaysan (xavf yo'q)
   GitHub qisqa muddatli token beradi, AWS ishonadi 10.6-bob
  permissions:
    id-token: write           OIDC token so'rash uchun

   Secret'ni HECH QACHON echo qilma / log'ga chiqarma / kodga yozma

Secret — maxfiy qiymat (parol, kalit, token), hech qachon kodga yozilmaydi. Repo secrets — GitHub UI'da kiritiladi (Settings Secrets and variables Actions), workflow'da ${{ secrets.NOM }} bilan ishlatiladi (masalan secrets.SSH_PRIVATE_KEY); log'da avtomatik yashiriladi (*** ko'rinadi). GITHUB_TOKEN — har run'da avtomatik beriladi (alohida yaratmaysiz), repo'ga cheklangan huquqi bor (kod push, GHCR'ga image — 10.4); permissions bloki bilan huquqni cheklash kerak (eng kam imtiyoz — 10.1: 2.4 — masalan contents: read, push kerak bo'lsa packages: write). OIDC (OpenID Connect) — secret'siz bulutga kirish (eng zamonaviy, 2026): uzoq muddatli AWS kalitni saqlamaysiz; GitHub qisqa muddatli token beradi, AWS unga ishonadi (permissions: id-token: write — 10.6). Oltin qoida: secret'ni hech qachon echo qilma, log'ga chiqarma, kodga yozma. Workflow .yml fayl ochiq (repo'da ko'rinadi) — unda faqat secrets.X havolasi, qiymat emas 14.5-bob.

2.9. Caching va artifact (tezlik va natija)

text
  CACHE — qayta yuklanadigan fayllarni saqlash (TEZLIK):
  Muammo: har run npm install ~2 daqiqa (node_modules qayta yuklanadi)
  Yechim: bir marta yukla, KESHLA, keyingi run tayyor oladi

  - uses: actions/setup-node@v4
    with:
      node-version: "20"
      cache: "npm"             npm keshini AVTOMATIK boshqaradi (eng oson)
   package-lock.json o'zgarmasa — keshdan oladi (sekundlar)

  ARTIFACT — job natijasini SAQLASH (job'lar/yuklab olish uchun):
  Muammo: test job dist/ qurdi, deploy job uni KO'RMAYDI 2.6-bob
  Yechim: build job artifact YUKLAYDI, deploy YUKLAB OLADI

  - uses: actions/upload-artifact@v4      build job'da
    with: { name: dist, path: dist/ }
  - uses: actions/download-artifact@v4    deploy job'da
    with: { name: dist }

   CACHE — tezlik (qayta yuklamaslik) ; ARTIFACT — natija uzatish/saqlash

Cache va artifact — ikki xil maqsad (aralashtirma): Cache (actions/cache@v4 yoki setup-node'ning cache: "npm") — tezlik uchun: har run'da npm install ~2 daqiqa (node_modules qayta yuklanadi); kesh bilan bir marta yuklab saqlanadi, keyingi run tayyor oladi (sekundlar). Kesh kalit (key) bilan ishlaydi — odatda package-lock.json hash'idan (lockfile o'zgarmasa — keshdan; o'zgarsa — yangi yuklab qayta keshlaydi — 5.2). setup-node'ning cache: "npm" buni avtomatik qiladi (eng oson). Artifact (upload-artifact/download-artifact) — natija uzatish/saqlash: build job dist/ qurdi, lekin deploy job uni ko'rmaydi (har job toza mashina — 2.6); build job artifact yuklaydi, deploy yuklab oladi. Artifact'ni inson ham yuklab oladi (run sahifasidan — masalan test hisoboti, .apk fayl). Qisqasi: cache = qayta yuklamaslik (tezlik), artifact = job'lararo/odam uchun natija.

2.10. Environment va approval (manual gate)

text
  ENVIRONMENT — deploy maqsadini ifodalaydi (staging, production):

  jobs:
    deploy:
      environment: production    bu job production muhitiga deploy qiladi
      runs-on: ubuntu-latest

  HIMOYA QOIDALARI (Settings  Environments  production):
   Required reviewers — deploy oldidan ODAM TASDIQI (manual gate)
     production'ga chiqishdan oldin senior "Approve" bosadi (CD Delivery)
   Wait timer — N daqiqa kutish (shoshilinch qaytarish imkoni)
   Deployment branches — faqat main'dan deploy (boshqa branch'dan yo'q)
   Environment secrets — shu muhitga xos secret (prod DB paroli)

  ┌──────┐   ┌──────┐   ┌─────────────┐   ┌────────────┐
  │ test │──▶│build │──▶│ APPROVAL?  │──▶│ deploy prod│
  └──────┘   └──────┘   └─────────────┘   └────────────┘
                         (odam Approve bosguncha kutadi)

   production deploy'ga ALBATTA approval qo'y (xato deploy qaytarib bo'lmaydi)

Environment (muhit) — deploy maqsadini ifodalaydi (staging, production). Job'ga environment: production qo'shilsa, GitHub o'sha muhitning himoya qoidalarini qo'llaydi (Settings Environments'da sozlanadi): Required reviewers — deploy oldidan odam tasdiqi (manual gate — senior "Approve" bosguncha job kutadi — bu aynan Continuous Delivery — 2.1); Wait timer — N daqiqa kutish (xato bo'lsa qaytarish oynasi); Deployment branches — faqat main'dan deploy (boshqa branch'dan production'ga chiqib bo'lmaydi); Environment secrets — shu muhitga xos secret (prod DB paroli — staging'da boshqa). Eng muhim amaliyot: production deploy'ga albatta approval qo'y — xato deploy ba'zan qaytarib bo'lmaydi (DB migratsiyasi, o'chirilgan ma'lumot). Staging — avtomatik (tez), production — tasdiq bilan (xavfsiz). Bu — CD'ni xavfsiz qiladigan asosiy mexanizm.

2.11. Tipik pipeline va deploy strategiyalari

text
  TIPIK PIPELINE BOSQICHLARI (ketma-ket, har biri o'tishi shart):

  1. CHECKOUT      kodni ol (actions/checkout)
  2. SETUP         Node/Docker o'rnat (setup-node)
  3. INSTALL       npm ci (lockfile'dan aniq versiya — 5.2)
  4. LINT          npm run lint (ESLint — kod sifati — 15.3)
  5. TEST          npm test (Jest — unit/e2e — 8.11)
  6. BUILD         npm run build (dist/ — TS compile)
  7. DOCKER        image qurish + registry'ga push (10.3, 10.4)
  8. DEPLOY        serverga chiqarish (quyidagi 3 usuldan biri)

  DEPLOY STRATEGIYALARI:
  A) SSH + buyruq   appleboy/ssh-action: serverda "git pull && restart"
  B) Docker pull    server "docker compose pull && up -d" 10.4-bob
  C) rsync          fayllarni serverga sinxron (10.1: 2.11)

   TARTIB MUHIM: avval lint/test (arzon, tez)  keyin build/deploy
   test FAIL bo'lsa, deploy'gacha YETMAYDI (buzuq kod chiqmaydi)

Tipik pipeline — bosqichlar ketma-ket (har biri o'tishi shart): checkout (kod) setup (Node/Docker) install (npm ci — lockfile'dan aniq, takrorlanadigan — 5.2) lint (ESLint — 15.3) test (Jest — 8.11) build (dist/) docker (image qurish + push — 10.3/10.4) deploy (serverga). Deploy strategiyalari (uchta keng tarqalgan): (A) SSH + buyruqappleboy/ssh-action bilan serverda git pull && systemctl restart yoki docker compose up 10.1-bob; (B) Docker pull — image registry'ga push qilingach, server docker compose pull && up -d qiladi (10.4 — eng toza); (C) rsync — fayllarni serverga sinxronlash (kichik loyiha — 10.1: 2.11). Tartib muhim: avval arzon/tez bosqichlar (lint, test), keyin qimmat (build, deploy). Test fail bo'lsa, deploy'gacha yetmaydi — buzuq kod production'ga chiqmaydi. Bu — CI/CD'ning butun ma'nosi.

2.12. Reusable workflows va branch protection

text
  REUSABLE WORKFLOW — bir workflow'ni boshqasidan chaqirish (DRY):
  Muammo: 5 ta repo'da bir xil CI yozish (takror — 15.1)
  Yechim: bir umumiy workflow, hammasi chaqiradi (workflow_call)

  # .github/workflows/reusable-ci.yml (umumiy)
  on:
    workflow_call:               boshqa workflow chaqira oladi

  # ishlatuvchi workflow:
  jobs:
    ci:
      uses: ./.github/workflows/reusable-ci.yml
      secrets: inherit           secret'larni uzatish

  BRANCH PROTECTION (Settings  Branches) — CI'ni MAJBURIY qilish:
   Require status checks — CI o'tmasa, PR merge BO'LMAYDI 4.3-bob
   Require PR review — kamida 1 odam ko'rib chiqsin (code review — 15.2)
   Require up to date — eng yangi main bilan (konflikt oldini olish)

   Branch protection'siz CI — "tavsiya" (hech kim majbur emas)
   Branch protection bilan — qizil CI = merge YO'Q (sifat kafolati)

Reusable workflow — bir workflow'ni boshqasidan chaqirish (DRY — takrorlamaslik — 15.1): 5 ta repo'da bir xil CI yozish o'rniga, bitta umumiy workflow yoziladi (on: workflow_call), qolganlar chaqiradi (uses: ./.github/workflows/reusable-ci.yml, secrets: inherit bilan secret uzatadi). Branch protection (Settings Branches) — CI'ni majburiy qiladi: Require status checks (CI yashil bo'lmasa PR merge bo'lmaydi — 4.3); Require PR review (kamida 1 odam code review qilsin — 15.2); Require up to date (PR eng yangi main bilan). Muhim farq: branch protection'siz CI shunchaki "tavsiya" (kimdir e'tiborsiz qoldirib merge qilishi mumkin); branch protection bilan — qizil CI = merge yo'q (bu — CI'ning haqiqiy kuchi, sifat kafolati). CI sozlash + branch protection — birga ishlaydi.

2.13. Concurrency — takror run'larni bekor qilish

text
  CONCURRENCY — bir vaqtda faqat bitta run (eskisini bekor qiladi):
  Muammo: bitta PR'ga 5 ta commit ketma-ket  5 ta CI run (4 tasi keraksiz)

  concurrency:
    group: ci-${{ github.ref }}        guruh kaliti (branch/PR bo'yicha)
    cancel-in-progress: true           shu guruhda eski run'ni BEKOR qil

   yangi push kelsa, o'sha branch'ning eski (tugamagan) run'i to'xtaydi
   faqat oxirgi commit tekshiriladi (vaqt/pul tejaladi)

   DEPLOY job'da EHTIYOT: cancel-in-progress: false (yarim deploy XAVFLI)
   deploy uchun group qo'y, lekin bekor qilma (navbatga tur)

Concurrency — bir guruhda bir vaqtda faqat bitta run ishlashini kafolatlaydi. Muammo: bitta PR'ga tez-tez commit qilinsa, har biriga alohida CI run boshlanadi — eski (allaqachon eskirgan) run'lar bekorga runner vaqtini yeydi. Yechim: concurrency bloki bilan group (odatda github.ref — branch/PR bo'yicha) va cancel-in-progress: true — shu guruhda yangi run boshlanganda eski, tugamagan run avtomatik bekor qilinadi, faqat oxirgi commit tekshiriladi. Muhim istisno: deploy job'ida cancel-in-progress: false qo'ying — yarim tugagan deploy'ni o'rtada bekor qilish serverni buzuq holatda qoldirishi mumkin (fayllar yarim ko'chirilgan, migratsiya yarim). Deploy uchun concurrency guruhi navbat hosil qiladi (biri tugab, keyingisi boshlanadi), lekin bekor qilmaydi. Concurrency — vaqt va pul (runner daqiqasi) tejashning eng oson usuli.

2.14. OIDC — parolsiz bulut autentifikatsiyasi

text
  OIDC (OpenID Connect) — SECRET'SIZ bulutga kirish (2026 standarti):

  ESKI USUL (xavfli):
   AWS access key + secret'ni repo secret'ga yozasiz
   uzoq muddatli kalit (leak bo'lsa — abadiy xavf, qo'lda rotate)

  OIDC USUL (xavfsiz):
  1. GitHub Actions run vaqtida QISQA MUDDATLI token so'raydi (id-token)
  2. AWS/GCP/Azure GitHub'ni "ishonchli identity provider" deb tan oladi
  3. AWS qisqa muddatli (1 soat) STS credential beradi (rol orqali)
  4. Kalit HECH QAYERDA saqlanmaydi (har run yangi, o'z-o'zidan tugaydi)

  permissions:
    id-token: write         OIDC token so'rash MAJBURIY
    contents: read

  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789:role/gha-deploy
      aws-region: eu-central-1
  # secret YO'Q — parolsiz!

   AWS tomonda: IAM OIDC provider + trust policy (repo'ni cheklaydi)

OIDC (OpenID Connect) — parolsiz bulut autentifikatsiyasi, 2026'da AWS/GCP/Azure'ga deploy'ning standart usuli. Eski usulda uzoq muddatli bulut kaliti (AWS access key) repo secret'ga yozilardi — leak bo'lsa abadiy xavf, qo'lda almashtirish kerak. OIDC'da secret umuman yo'q: (1) run vaqtida GitHub qisqa muddatli token beradi (permissions: id-token: write majburiy); (2) bulut GitHub'ni "ishonchli identity provider" deb tan oladi; (3) aws-actions/configure-aws-credentials bilan GitHub token'ini AWS roliga almashtiradi (1 soatlik STS credential); (4) kalit hech qayerda saqlanmaydi, har run yangi va o'z-o'zidan tugaydi. Bulut tomonda bir martalik sozlash kerak: AWS'da IAM OIDC provider yaratiladi va trust policy faqat sizning repo/branch'ingizga ruxsat beradi (repo:owner/name:ref:refs/heads/main). Bu — supply-chain xavfsizligining muhim yutug'i 10.6-bob. Batafsil AWS sozlash — 10.6-bobda.

2.15. Composite action va reusable workflow farqi

text
  IKKI XIL "QAYTA ISHLATISH" — aralashtirmaslik kerak:

  COMPOSITE ACTION — bir nechta STEP'ni bitta action'ga o'raydi:
   action.yml faylida (repo/.github/actions/setup/action.yml)
   step darajasida ishlaydi (uses: ./.github/actions/setup)
   maqsad: takrorlanadigan STEP KETMA-KETLIGI (checkout+node+ci)

  # .github/actions/setup/action.yml
  runs:
    using: composite
    steps:
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
        shell: bash             composite'da shell MAJBURIY

  REUSABLE WORKFLOW — butun JOB(lar)ni qayta ishlatadi 2.12-bob:
   on: workflow_call ; uses: ...reusable.yml (job darajasida)
   maqsad: butun PIPELINE'ni ulashish (bir nechta job, runner)

   Composite = step'lar bloki (bir job ichida) ; Reusable = job'lar (butun oqim)

Composite action va reusable workflow — ikkalasi ham qayta ishlatish uchun, lekin boshqa darajada. Composite action — bir nechta stepni bitta action'ga o'raydi (action.yml faylida using: composite), uses: ./.github/actions/<nom> bilan job ichida ishlatiladi. Maqsad: har workflow'da takrorlanadigan step ketma-ketligi (masalan checkout + setup-node + npm ci) o'rniga bitta action. Composite step'da run: uchun shell majburiy (shell: bash). Reusable workflow 2.12-bob — butun job(lar)ni qayta ishlatadi (on: workflow_call), uses: ...reusable.yml bilan job darajasida chaqiriladi. Qisqasi: composite = step'lar bloki (bir job ichida qayta ishlatiladi); reusable = butun job'lar oqimi (bir nechta job, runner). Kichik takror uchun composite, butun pipeline uchun reusable.

2.16. Deployment strategiyalari (blue-green, canary, rolling)

text
  DEPLOY STRATEGIYALARI — yangi versiyani XAVFSIZ chiqarish:

  1) RECREATE (eng oddiy — downtime bor):
     eskisini o'chir  yangisini yoq (bir necha soniya ilova o'chadi)

  2) ROLLING (bosqichma-bosqich — downtime yo'q):
     N ta nusxadan bittasini yangila  sog'lom bo'lsa keyingisini...
      eski va yangi versiya BIR VAQTDA ishlaydi (mos bo'lishi kerak)

  3) BLUE-GREEN (ikki muhit — bir zumda almashtirish):
     BLUE (joriy, jonli) + GREEN (yangi, tayyorlanadi)
      GREEN test'dan o'tsa  trafik BLUE'dan GREEN'ga o'tkaziladi (LB)
      xato bo'lsa — bir zumda BLUE'ga qaytariladi (tez rollback)
      ikki barobar resurs kerak (ikki to'liq muhit)

  4) CANARY (asta-sekin — eng ehtiyotkor):
     yangi versiyaga trafikning 5%  kuzat  25%  50%  100%
      xato metrika (5xx, latency) ko'rinsa — to'xtat, qaytar
      xatoni foydalanuvchilarning KICHIK qismi ko'radi (zarar kam)

   GitHub Actions — DEPLOY'ni ISHGA TUSHIRADI ; strategiyani platforma
     bajaradi (Kubernetes, ECS, Nginx/LB, Argo Rollouts)

Deployment strategiyalari — yangi versiyani ishlab turgan tizimga xavfsiz chiqarish usullari. (1) Recreate — eskisini o'chirib yangisini yoqish (eng oddiy, lekin bir necha soniya downtime). (2) Rolling — nusxalarni bittalab yangilash (bittasini yangila, sog'lom bo'lsa keyingisini); downtime yo'q, lekin eski va yangi versiya bir vaqtda ishlaydi — ular mos bo'lishi shart (DB sxemasi, API). (3) Blue-green — ikki to'liq muhit: blue (joriy jonli) va green (yangi, tayyorlanadi); green test'dan o'tgach, load balancer trafikni bir zumda green'ga o'tkazadi, xato bo'lsa bir zumda blue'ga qaytariladi (juda tez rollback); kamchilik — ikki barobar resurs. (4) Canary — yangi versiyaga trafikning kichik qismini (5%) yo'naltirib kuzatish (xato metrika — 5xx, kechikish — ko'rinsa to'xtatish), sog'lom bo'lsa asta 2550100% oshirish; xatoni eng kam foydalanuvchi ko'radi. Muhim tushuncha: GitHub Actions deploy'ni ishga tushiradi, lekin strategiyaning o'zini platforma bajaradi — Kubernetes (rolling default), AWS ECS (blue-green/canary CodeDeploy bilan), Nginx/HAProxy (LB o'tkazish), Argo Rollouts (canary). Workflow platformaga "yangi versiya tayyor" deb signal beradi.

2.17. Rollback — buzuq deploy'ni qaytarish

text
  ROLLBACK — production yiqilganda oldingi ishlaydigan versiyaga qaytish:

  MUHIM QOIDA: har deploy IZLANADIGAN versiya bilan (latest EMAS):
   image:latest  qaysi kod ekani noma'lum (rollback qiyin)
   image:${{ github.sha }}  aniq commit (rollback = oldingi SHA)

  ROLLBACK USULLARI:
  1) Docker teg orqali: serverda oldingi image tegini qayta yoq
     docker compose up -d  (image: ...:<oldingi-sha>)
  2) Git orqali: git revert <buzuq-commit>  push  CI qayta deploy
  3) Blue-green: LB'ni blue'ga qaytar (soniyalar — 2.16)
  4) workflow_dispatch: "rollback" workflow, input: qaysi versiyaga

   DB migratsiyasi — ROLLBACK QIYIN (oldga mos migratsiya yozing)
   deploy oldidan backup 10.8-bob, migratsiya orqaga qaytadigan bo'lsin

Rollback — production buzilganda oldingi ishlaydigan versiyaga tez qaytish. Buning uchun eng muhim shart — har deploy izlanadigan (immutable) versiya bilan bo'lishi: image:latest emas, image:${{ github.sha }} (aniq commit) — shunda rollback = "oldingi SHA'ni qayta yoqish". Usullar: (1) Docker teg — serverda oldingi image tegi bilan docker compose up -d; (2) Git revertgit revert <buzuq-commit> push CI toza kodni qayta deploy qiladi (audit izi qoladi — eng toza); (3) Blue-green — load balancer'ni blue'ga qaytarish (soniyalar — 2.16); (4) workflow_dispatch — maxsus "rollback" workflow (input: qaysi versiyaga). Eng qiyin joy — DB migratsiyasi: kod rollback qilinsa ham, DB sxemasi allaqachon o'zgargan bo'lishi mumkin. Yechim: orqaga mos (backward-compatible) migratsiya yozish va deploy oldidan backup olish 10.8-bob. Rollback rejasi — deploy avtomatlashtirishning ajralmas qismi (deploy'ga ishonch shundan).

2.18. Xavfsizlik skani — Dependabot, CodeQL

text
  AVTOMATIK XAVFSIZLIK — kod va bog'liqliklarni tekshirish:

  DEPENDABOT — eskirgan/xavfli paketlarni topadi va PR ochadi:
  # .github/dependabot.yml
  version: 2
  updates:
    - package-ecosystem: "npm"
      directory: "/"
      schedule: { interval: "weekly" }    har hafta yangilanish tekshiradi
   xavfli paket topilsa — avtomatik "bump" PR (siz merge qilasiz)

  CODEQL — kodni statik tahlil (SQL injection, XSS... topadi):
  # .github/workflows/codeql.yml
  - uses: github/codeql-action/init@v3
    with: { languages: javascript }
  - uses: github/codeql-action/analyze@v3
   topilgan zaifliklar "Security" tab'da (14-qism)

   Ikkalasi ham GitHub'da BEPUL (public repo) — ALBATTA yoqing

Xavfsizlik skani — GitHub'ning ikki bepul avtomatik vositasi (2026'da har jiddiy repo'da bo'lishi kerak). Dependabot — loyihaning bog'liqliklarini (npm paketlar) kuzatadi: eskirgan yoki ma'lum zaifligi (CVE) bor paket topilsa, uni yangilaydigan PR avtomatik ochadi (.github/dependabot.yml faylida sozlanadi — package-ecosystem: npm, schedule). Siz PR'ni ko'rib merge qilasiz — CI o'tsa, xavfsizroq versiya keladi. CodeQL — GitHub'ning statik kod tahlili (kodni ishga tushirmay o'qib zaiflik qidiradi — SQL injection, XSS, hardcoded secret); workflow'da github/codeql-action/init + analyze bilan yoqiladi, natijalar repo'ning Security tab'ida ko'rinadi (14-qism). Ikkalasi ham public repo'da bepul — CI/CD sozlaganda ularni ham yoqish DevSecOps ("xavfsizlikni pipeline'ga singdirish") amaliyotining asosidir.

2.19. Monorepo, badge, boshqa CI platformalar

text
  MONOREPO — bir repo'da ko'p paket/servis (path filter MUHIM):
  on:
    push:
      paths: ["apps/api/**"]     faqat api o'zgarsa — api CI ishlaydi
   har servisga alohida workflow (yoki path filter)
   Turbo/Nx: faqat O'ZGARGAN paketni build/test (affected — tez)

  BADGE — README'da CI holati belgisi (yashil/qizil):
  ![CI](https://github.com/OWNER/REPO/actions/workflows/ci.yml/badge.svg)
   repo ochilganda darrov ko'rinadi: build o'tyaptimi

  BOSHQA CI PLATFORMALAR (konsept bir xil):
  GitLab CI — .gitlab-ci.yml (stages/jobs; GitLab'ga qurilgan)
  Jenkins   — Jenkinsfile (o'z serveri; eski, kuchli, plugin ko'p)
  CircleCI  — .circleci/config.yml (SaaS)

   Tushuncha KO'CHADI: pipeline/stage/job/artifact — hamma joyda bir xil

Monorepo — bitta repo'da bir nechta paket/servis (masalan apps/api, apps/web, packages/ui). Bu yerda paths filtr hal qiluvchi: faqat apps/api/** o'zgarsa api CI'sini ishga tushirish (har mayda o'zgarishda hamma narsani qayta qurmaslik — 2.5). Kattaroq monorepo'da Turbo yoki Nx ishlatiladi — ular faqat o'zgargan (affected) paketni build/test qiladi va natijalarni keshlaydi (juda tez). Badge — README'da CI holatining yashil/qizil belgisi (.../badge.svg havolasi) — repo ochilganda build sog'ligini darrov ko'rsatadi (ochiq loyihalarda odat). Boshqa CI platformalari — tushunchalar bir xil (faqat sintaksis boshqa): GitLab CI (.gitlab-ci.yml — stages/jobs, GitLab'ga qurilgan), Jenkins (Jenkinsfile — o'z serverida, eski va kuchli, plugin ko'p), CircleCI (SaaS). Eng muhim xulosa: pipeline / stage(job) / step / artifact / cache tushunchalari hamma platformada bir xil — GitHub Actions'ni o'rgansangiz, boshqasiga o'tish faqat sintaksis masalasi.


3. Sintaksis — tez ma'lumotnoma

text
JOY 2.3-bob:  .github/workflows/ci.yml  (YAML, 2 probel indent, tab YO'Q)
TRIGGER 2.5-bob: on: push|pull_request|schedule(cron)|workflow_dispatch
FILTR 2.5-bob:   branches: [main] | paths: ["src/**"] | tags: ["v*"]
JOB 2.2-bob:     jobs: <id>: runs-on: ubuntu-latest, steps: [...]
NEEDS 2.6-bob:   needs: [lint, test]  (sequential — o'tgach ishlaydi)
MATRIX 2.6-bob:  strategy: matrix: node: [18,20,22]  (parallel ko'p versiya)
ACTION 2.7-bob:  uses: actions/checkout@v4  |  with: { key: val }
BUYRUQ 2.3-bob:  run: npm ci  |  run: |  (ko'p qatorli)
SECRET 2.8-bob:  ${{ secrets.SSH_KEY }}  |  GITHUB_TOKEN (avto)
PERMS 2.8-bob:   permissions: { contents: read, packages: write }
CACHE 2.9-bob:   setup-node with cache:"npm"  |  actions/cache@v4
ARTIFACT 2.9-bob: upload-artifact@v4 / download-artifact@v4
ENV 2.10-bob:    environment: production  (approval gate)
CONCURR 2.13-bob: concurrency: { group: ..., cancel-in-progress: true }
OIDC 2.14-bob:   permissions: id-token: write  (parolsiz bulut)
COMPOSITE 2.15-bob: action.yml  using: composite  (step'lar bloki)
KONTEKST:      ${{ github.sha }} ${{ github.ref }} ${{ env.X }}
IF (shart):    if: github.ref == 'refs/heads/main'

4. Batafsil kod namunalari

Misol 1 — Minimal CI (lint + test, har push'da)

yaml
# .github/workflows/ci.yml — eng oddiy CI (boshlang'ich)
name: CI                                    # workflow nomi (UI'da ko'rinadi)

on:                                         # QACHON ishga tushadi (2.5)
  push:
    branches: [main]                        # main'ga push'da
  pull_request:                             # va har PR'da (4.3)
    branches: [main]

jobs:
  test:                                     # job ID (o'zing tanlaysan)
    runs-on: ubuntu-latest                  # GitHub-hosted Linux runner (2.4)
    steps:
      - uses: actions/checkout@v4           # 1. kodni runner'ga ol (MAJBURIY birinchi)
      - uses: actions/setup-node@v4         # 2. Node.js o'rnat (2.7)
        with:
          node-version: "20"                # qaysi Node versiyasi
          cache: "npm"                      # npm keshini avto boshqar (tezlik — 2.9)
      - run: npm ci                         # 3. paket o'rnat (lockfile'dan — aniq, 5.2)
      - run: npm run lint                   # 4. ESLint (kod sifati — 15.3)
      - run: npm test                       # 5. testlar (Jest — 8.11)
#  Birorta qadam FAIL bo'lsa  butun job qizil  PR'da "X" belgi

Misol 2 — Matrix build (ko'p Node versiya — parallel)

yaml
# Kutubxonani bir nechta Node versiyada sinash (kengroq mosllik — 2.6)
name: Matrix CI
on: [push, pull_request]                    # qisqa shakl (har ikkisida)

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false                      # bittasi fail bo'lsa, boshqalar TO'XTAMASIN
      matrix:
        node-version: [18, 20, 22]          # 3 ta Node — 3 ta PARALLEL job
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}   # matrix qiymatini ol
          cache: "npm"
      - run: npm ci
      - run: npm test
#  matrix  3 ta alohida job (Node 18, 20, 22) — bir vaqtda (tez)
#  fail-fast:false  Node 18 yiqilsa ham, 20/22 davom etadi (to'liq ko'rinish)

Misol 3 — OS matrix (ko'p platforma)

yaml
# Ilovani Linux + Windows + macOS'da sinash (cross-platform — 2.6)
jobs:
  test:
    runs-on: ${{ matrix.os }}               # matrix'dan runner tanlanadi
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node-version: [20, 22]              # OS × Node = 3×2 = 6 ta job
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test
#  matrix kombinatsiya: 3 OS × 2 Node = 6 parallel job (to'liq qamrov)

Misol 4 — Build artifact (build natijasini saqlash — 2.9)

yaml
# Build qil, dist/ ni artifact sifatida saqla (keyingi job/yuklab olish)
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run build                  # dist/ papka hosil bo'ladi (TS compile)
      - uses: actions/upload-artifact@v4    # dist/ ni SAQLA (2.9)
        with:
          name: dist                        # artifact nomi
          path: dist/                       # qaysi papka/fayl
          retention-days: 7                 # 7 kun saqlanadi (keyin o'chadi)
#  Endi run sahifasidan "dist" yuklab olinadi, yoki boshqa job download qiladi

Misol 5 — Docker image qurish va GHCR'ga push (10.3, 10.4)

yaml
# Docker image qurib, GitHub Container Registry (ghcr.io)'ga push
name: Docker Build
on:
  push:
    branches: [main]

jobs:
  docker:
    runs-on: ubuntu-latest
    permissions:                            # GITHUB_TOKEN huquqlari (eng kam — 2.8)
      contents: read
      packages: write                       # GHCR'ga push uchun MAJBURIY
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3 # Buildx (kesh/multi-platform — 2.7)
      - uses: docker/login-action@v3        # registry'ga login (10.4)
        with:
          registry: ghcr.io                 # GitHub Container Registry
          username: ${{ github.actor }}     # joriy foydalanuvchi (avto)
          password: ${{ secrets.GITHUB_TOKEN }}   # avto token (PAT kerak emas — 2.8)
      - uses: docker/build-push-action@v6   # qurish + push (10.3)
        with:
          context: .                        # Dockerfile qayerda
          push: true                        # qurgach push qil
          tags: ghcr.io/${{ github.repository }}:latest   # image tegi
#  ghcr.io/owner/repo:latest — endi server bu image'ni pull qiladi (10.4)

Misol 6 — SSH bilan serverga deploy (appleboy/ssh-action — 10.1)

yaml
# main'ga push'da serverga SSH orqali deploy (10.1: 2.8)
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: appleboy/ssh-action@v1        # SSH orqali serverda buyruq (2.7)
        with:
          host: ${{ secrets.SERVER_HOST }}        # server IP (secret — 2.8)
          username: ${{ secrets.SERVER_USER }}    # deploy user (10.1: 2.4)
          key: ${{ secrets.SSH_PRIVATE_KEY }}     # private kalit (secret — 10.1: 2.8)
          script: |                               # serverda bajariladigan buyruqlar
            cd /home/deploy/app
            git pull origin main                  # yangi kodni tort
            npm ci --omit=dev                      # prod paketlar
            npm run build
            sudo systemctl restart myapp           # ilovani qayta yoq (10.1: 2.6)
#  SSH_PRIVATE_KEY repo secret'da; serverda public kalit authorized_keys'da (10.1: 2.9)

Misol 7 — PR'da test + status check (CI gate — 4.3)

yaml
# Har PR'da test ishlaydi  yashil/qizil belgi (branch protection bilan — 2.12)
name: PR Check
on:
  pull_request:
    branches: [main]                        # main'ga qaratilgan PR'lar

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run lint                   # ESLint
      - run: npm run test:cov               # test + coverage (8.11)
      - run: npm run build                  # build ham buzilmasin
#  Bu job "validate"  branch protection'da REQUIRED qil (2.12)
#  qizil bo'lsa PR MERGE bo'lmaydi (buzuq kod main'ga kirmaydi — 4.3)

Misol 8 — To'liq pipeline (lint test build deploy)

yaml
# To'liq CI/CD: parallel tekshiruv  build  deploy (needs bilan — 2.6, 2.11)
name: CI/CD Pipeline
on:
  push:
    branches: [main]

jobs:
  lint:                                     # 1-job (parallel)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run lint

  test:                                     # 2-job (lint bilan PARALLEL)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm test

  deploy:                                   # 3-job (SEQUENTIAL — oxirgi)
    needs: [lint, test]                     # lint VA test o'tgach (2.6)
    runs-on: ubuntu-latest
    environment: production                 # approval gate (2.10)
    steps:
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: "cd /app && docker compose pull && docker compose up -d"  # 10.4
#  lint/test PARALLEL (tez)  ikkalasi o'tsa  deploy (approval kutadi — 2.10)

Misol 9 — Reusable workflow (takrorlamaslik — 2.12)

yaml
# === .github/workflows/reusable-test.yml (UMUMIY — bir marta yoziladi) ===
name: Reusable Test
on:
  workflow_call:                            # boshqa workflow CHAQIRA oladi (2.12)
    inputs:
      node-version:
        type: string
        default: "20"
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: ${{ inputs.node-version }}, cache: "npm" }
      - run: npm ci
      - run: npm test

# === .github/workflows/ci.yml (CHAQIRUVCHI) ===
# on: [push]
# jobs:
#   call-test:
#     uses: ./.github/workflows/reusable-test.yml   # umumiyni chaqir
#     with: { node-version: "22" }
#     secrets: inherit                              # secret'larni uzat
#  10 ta repo'da bir xil CI o'rniga — 1 umumiy, hammasi chaqiradi (DRY — 15.1)

Misol 10 — Manual deploy + environment input (workflow_dispatch — 2.5)

yaml
# Qo'lda ishga tushiriladigan deploy — qaysi muhitga tanlash bilan
name: Manual Deploy
on:
  workflow_dispatch:                        # UI'dan "Run workflow" tugmasi (2.5)
    inputs:
      target:
        description: "Qaysi muhitga deploy?"
        type: choice
        options: [staging, production]      # tanlov ro'yxati
        default: staging

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.target }}       # tanlangan muhit (approval — 2.10)
    steps:
      - uses: actions/checkout@v4
      - name: Deploy xabari
        run: echo "Deploy  ${{ inputs.target }} (commit ${{ github.sha }})"
      - uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: "cd /app && ./deploy.sh ${{ inputs.target }}"
#  production tanlansa — environment qoidasi approval so'raydi (2.10)

Misol 11 — Concurrency + coverage'li to'liq CI (linttestbuild)

yaml
# Takror run'larni bekor qiluvchi, coverage artifact chiqaruvchi CI (2.13, 2.9)
name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

concurrency:                                # takror run'larni bekor qil (2.13)
  group: ci-${{ github.ref }}               # branch/PR bo'yicha guruh
  cancel-in-progress: true                  # eski (tugamagan) run to'xtaydi

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run lint

  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run test:cov               # test + coverage hisobot (8.11)
      - uses: actions/upload-artifact@v4    # coverage'ni artifact qil (2.9)
        with:
          name: coverage
          path: coverage/
          retention-days: 7

  build:
    needs: [lint, test]                     # ikkalasi o'tgach (2.6)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: "20", cache: "npm" }
      - run: npm ci
      - run: npm run build
#  PR'ga tez commit qilinsa — eski run bekor bo'ladi (faqat oxirgisi — 2.13)

Misol 12 — Composite action (takror step'larni o'rash — 2.15)

yaml
# === .github/actions/setup/action.yml (composite — bir marta yoziladi) ===
name: "Setup Node loyihasi"
description: "Node o'rnatadi, kesh bilan paketlarni tortadi"
inputs:
  node-version:
    default: "20"
runs:
  using: composite                          # composite action (2.15)
  steps:
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}
        cache: "npm"
    - run: npm ci
      shell: bash                           # composite'da shell MAJBURIY (2.15)

# === .github/workflows/ci.yml (ishlatuvchi) ===
# jobs:
#   test:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - uses: ./.github/actions/setup      # composite'ni ulash (checkout+node+ci)
#         with: { node-version: "22" }
#       - run: npm test
#  checkout+setup-node+npm ci takrori — bitta action'ga o'raldi (DRY — 2.15)

Misol 13 — OIDC bilan parolsiz AWS deploy (2.14, 10.6)

yaml
# AWS'ga SECRET'siz deploy — OIDC qisqa muddatli token bilan
name: Deploy AWS
on:
  push:
    branches: [main]

permissions:
  id-token: write                           # OIDC token so'rash MAJBURIY (2.14)
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production                  # approval gate (2.10)
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4   # OIDC  AWS rol (2.14)
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
      - run: aws s3 sync ./dist s3://my-app-bucket --delete   # S3'ga yuklash (10.6)
#  Hech qanday AWS secret YO'Q — GitHub token AWS roliga almashadi (2.14)

Misol 14 — Docker layer cache va SHA teg bilan rollback tayyor (2.13, 2.17)

yaml
# Docker image'ni tez qurish (layer cache) + izlanadigan SHA teg (rollback — 2.17)
name: Docker
on:
  push:
    branches: [main]

concurrency:
  group: docker-${{ github.ref }}
  cancel-in-progress: false                 # image qurishni o'rtada bekor qilma

jobs:
  docker:
    runs-on: ubuntu-latest
    permissions: { contents: read, packages: write }   # GHCR push (2.8)
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |                            # IKKI teg — latest va aniq SHA
            ghcr.io/${{ github.repository }}:latest
            ghcr.io/${{ github.repository }}:${{ github.sha }}   # rollback uchun (2.17)
          cache-from: type=gha               # GitHub Actions cache'dan o'qi (2.9)
          cache-to: type=gha,mode=max        # layer'larni cache'ga yoz (tez qayta qurish)
#  :${{ github.sha }} — rollback = serverda oldingi SHA image'ni yoqish (2.17)

Misol 15 — Dependabot va CodeQL (avtomatik xavfsizlik — 2.18)

yaml
# === .github/dependabot.yml (bog'liqliklarni kuzatadi — PR ochadi) ===
version: 2
updates:
  - package-ecosystem: "npm"                # npm paketlari
    directory: "/"
    schedule:
      interval: "weekly"                    # har hafta yangilanish tekshiradi
  - package-ecosystem: "github-actions"     # action versiyalarini ham kuzat
    directory: "/"
    schedule:
      interval: "weekly"

# === .github/workflows/codeql.yml (statik xavfsizlik tahlili) ===
# name: CodeQL
# on:
#   push: { branches: [main] }
#   schedule: [{ cron: "0 3 * * 1" }]        # har dushanba 03:00 UTC (2.5)
# jobs:
#   analyze:
#     runs-on: ubuntu-latest
#     permissions: { security-events: write, contents: read }
#     steps:
#       - uses: actions/checkout@v4
#       - uses: github/codeql-action/init@v3
#         with: { languages: javascript }
#       - uses: github/codeql-action/analyze@v3
#  Dependabot = paket zaifligi PR ; CodeQL = kod zaifligi (Security tab — 2.18)

5. To'g'ri va noto'g'ri holatlar

1) Action versiyasi

text
 uses: actions/checkout@main (har o'zgarishda buzilishi mumkin — 2.7)
 uses: actions/checkout@v4 (versiya qadalgan — barqaror)

2) Secret bilan ishlash

text
 run: echo ${{ secrets.DB_PASSWORD }} (log'ga chiqishi xavfi — 2.8)
 env: DB_PASSWORD: ${{ secrets.DB_PASSWORD }} (env orqali, log'da ***)

3) Paket o'rnatish

text
 npm install (lockfile yangilanadi, har run boshqa versiya — 5.2)
 npm ci (lockfile'dan AYNAN, takrorlanadigan, tez — CI uchun)

4) Job'lar orasida fayl

text
 build job dist/ qurdi, deploy job ishlatadi (toza mashina — KO'RMAYDI — 2.6)
 upload-artifact (build)  download-artifact (deploy) — 2.9

5) Test va deploy tartibi

text
 deploy avval, test keyin (buzuq kod chiqib ketadi — 2.11)
 needs: [test] — test o'tgach deploy (CI gate — 2.6)

6) Production deploy

text
 har push avtomatik production'ga (xato darrov foydalanuvchida — 2.10)
 environment: production + required reviewers (approval gate)

7) GITHUB_TOKEN huquqi

text
 permissions: write-all (haddan ortiq huquq — xavf — 2.8)
 permissions: { contents: read, packages: write } (eng kam — 10.1: 2.4)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Secret leak (maxfiy qiymat log'da ko'rindi)

Sababi: secret'ni echo qildi, yoki with'da ochiq yozildi, yoki fork PR'da chiqdi. Yechimi: secret'ni faqat ${{ secrets.X }} orqali ishlat, hech qachon echo/print qilma; agar leak bo'lsa — secret'ni darrov bekor qil va yangisini yarat (rotate); fork PR'da secret avtomatik berilmaydi (2.8, 14.5).

Xato 2 — Permission denied (publickey) SSH deploy'da

Sababi: SSH_PRIVATE_KEY secret noto'g'ri/to'liq emas, yoki public kalit serverda authorized_keys'da yo'q, yoki user/host xato. Yechimi: private kalitni to'liq (BEGIN/END qatorlari bilan) secret'ga joyla; serverda public kalit borligini tekshir (ssh-copy-id — 10.1: 2.9); host/username to'g'rimi tekshir 10.1-bob.

Xato 3 — Cache key noto'g'ri (kesh ishlamayapti yoki eski)

Sababi: kesh kaliti lockfile'ga bog'lanmagan (har doim eski kesh), yoki noto'g'ri path. Yechimi: setup-node'ning cache: "npm" ishlat (avtomatik to'g'ri key — lockfile hash'idan); qo'lda actions/cache@v4 ishlatsangiz, key'da hashFiles('**/package-lock.json') qo'sh 2.9-bob.

Xato 4 — Matrix fail-fast (bitta yiqilsa, hammasi to'xtaydi)

Sababi: default fail-fast: true — matrix'da bitta job fail bo'lsa, qolganlari bekor qilinadi (to'liq ko'rinish yo'q). Yechimi: strategy: fail-fast: false qo'sh — har bir matrix job mustaqil tugaydi (qaysi versiya muammoli — aniq ko'rinadi — 2.6, Misol 2).

Xato 5 — YAML indent xatosi (workflow umuman ishlamaydi)

Sababi: tab ishlatilgan (YAML tab'ni rad etadi), yoki noto'g'ri bo'sh joy, yoki - joyi xato. Yechimi: faqat probel (2 ta), tab yo'q; VS Code'da YAML linter qo'y; GitHub Actions tab'da xato qatori ko'rsatiladi — o'sha qatorni tekshir 2.3-bob.

Xato 6 — Token huquqi yetmasligi (403/Resource not accessible)

Sababi: GITHUB_TOKEN'da kerakli huquq yo'q (masalan GHCR push uchun packages: write yo'q), yoki repo Settings'da Actions huquqi cheklangan. Yechimi: permissions: blokiga kerakli huquqni qo'sh (packages: write, contents: write); repo Settings Actions Workflow permissions'ni tekshir (2.8, Misol 5).

Xato 7 — Deploy job'da dist/ yoki node_modules yo'q

Sababi: har job toza mashina — oldingi job natijasi yo'q 2.6-bob. Yechimi: build natijasini upload-artifact, deploy'da download-artifact; yoki deploy job'da npm ci && npm run build qaytadan bajar (2.9, Misol 4).

Xato 8 — Cheksiz tsikl yoki keraksiz ishga tushish

Sababi: workflow o'zi push qiladi yana push event yana workflow (loop), yoki har mayda o'zgarishda butun pipeline ishlaydi (sekin/qimmat). Yechimi: paths/branches filtr qo'y; bot commit'larni if: github.actor != 'github-actions[bot]' bilan o'tkaz; concurrency bilan eskisini bekor qil 2.5-bob.


7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Linux/SSH 10.1-bob: deploy job SSH kalit bilan serverga ulanadi (appleboy/ssh-action, SSH_PRIVATE_KEY secret).
  • Docker 10.3-bob: CI image quradi (docker/build-push-action).
  • Docker Compose 10.4-bob: server docker compose pull && up -d bilan yangilanadi.
  • Cloud/AWS 10.6-bob: OIDC bilan secret'siz AWS'ga deploy (ECR, ECS, S3).
  • Test 8.11-bob: har push/PR'da Jest unit/e2e avtomatik (CI yadrosi).
  • Git/PR 4.3-bob: pull_request trigger, branch protection — CI gate.
  • Conventional commits 4.5-bob: commit'dan changelog/release avtomatik.
  • ESLint/Prettier/Husky 15.3-bob: lint CI'da takrorlanadi (mahalliy + server).
  • Secrets (10.11, 14.5): repo secrets, OIDC, eng kam imtiyoz.
  • Monitoring 10.9-bob: deploy'dan keyin Sentry release, health check.

8. Eng yaxshi amaliyotlar (best practices)

  • Action versiyasini qada (@v4 yoki SHA — @main emas — barqarorlik/xavfsizlik — 2.7).
  • npm ci (lockfile'dan aniq, takrorlanadigan — npm install emas — 5.2).
  • Avval lint/test, keyin build/deploy (arzonqimmat; buzuq kod chiqmasin — 2.11).
  • Caching (setup-node cache:"npm" — har run 2 daqiqa tejaydi — 2.9).
  • Secret'ni hech qachon log'ga chiqarma (faqat ${{ secrets.X }}, env orqali — 2.8).
  • Eng kam imtiyoz (permissions: aniq — write-all emas — 10.1: 2.4).
  • OIDC (uzoq muddatli bulut kalitini saqlama — qisqa token — 2.8, 10.6).
  • Production'ga approval gate (environment + required reviewers — 2.10).
  • Branch protection (CI required qizil bo'lsa merge yo'q — 2.12, 4.3).
  • Matrix (ko'p Node/OS — fail-fast: false bilan to'liq qamrov — 2.6).
  • Reusable workflow (ko'p repo'da takrorlama — DRY — 2.12, 15.1).
  • paths/concurrency filtr (keraksiz/takror run'larni kamaytir — vaqt/pul — 2.5).

9. Amaliy loyiha: "To'liq CI/CD Pipeline"

NestJS (yoki Express) ilova uchun to'liq, real CI/CD pipeline qurish — har push'da avtomatik tekshiruv va deploy.

Maqsad

GitHub repozitoriyadagi backend ilova uchun GitHub Actions bilan to'liq pipeline yaratish: har PR'da lint/test (CI gate), main'ga merge bo'lganda Docker image qurib registry'ga push, va serverga avtomatik deploy (approval bilan production).

Talablar (requirements)

  1. CI workflow: pull_request'da lint + test + build ishlasin (Misol 1, 7, 2.5).
  2. Matrix: test'ni Node 20 va 22'da parallel sina (fail-fast: false — Misol 2, 2.6).
  3. Caching: setup-node cache:"npm" bilan tezlashtir (Misol 1, 2.9).
  4. Docker: main'ga push'da image qurib GHCR'ga push (packages: write — Misol 5, 10.3).
  5. Secrets: SSH_PRIVATE_KEY, SERVER_HOST repo secrets'da; hech qayerda ochiq emas 2.8-bob.
  6. Deploy: appleboy/ssh-action bilan serverda docker compose pull && up -d (Misol 6, 8, 10.4).
  7. needs: deploy faqat lint+test o'tgach (sequential — Misol 8, 2.6).
  8. Environment: production muhitiga required reviewers (approval gate — Misol 10, 2.10).
  9. Branch protection: main'da CI required + PR review (qizil = merge yo'q — 2.12, 4.3).
  10. Manual deploy: workflow_dispatch bilan qaysi muhitga deploy tanlash (Misol 10, 2.5).

Maslahatlar (hint)

  • YAML indent — faqat probel (2 ta), tab yo'q (Xato 5).
  • Avval kichik workflow'dan boshla (Misol 1), keyin job qo'sh (Misol 8).
  • Secret'ni avval GitHub UI'da yarat (Settings Secrets), keyin ${{ secrets.X }} ishlat.
  • SSH deploy'dan oldin serverda public kalit borligini tekshir (10.1: 2.9, Xato 2).
  • workflow_dispatch'ni sinash uchun Actions tab "Run workflow" tugmasi.
  • Server yo'q bo'lsa — deploy o'rniga echo/staging Docker konteynerga deploy qil.

"Tayyor" mezonlari (acceptance criteria)

  • PR ochilganda CI avtomatik ishlaydi (lint + test + build).
  • Matrix Node 20/22'da parallel ishlaydi (fail-fast: false).
  • Cache ikkinchi run'da install'ni tezlashtiradi.
  • main push'da Docker image GHCR'ga push bo'ladi.
  • Secret'lar hech qayerda ochiq emas (faqat secrets.X havola).
  • Deploy faqat lint+test o'tgach ishlaydi (needs).
  • Production deploy approval so'raydi (environment reviewers).
  • Branch protection: qizil CI bilan PR merge bo'lmaydi.
  • workflow_dispatch bilan qo'lda deploy ishlaydi (muhit tanlash).

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.


10. Xulosa va keyingi bobga ko'prik

Bu bobda CI/CD va GitHub Actions'ni chuqur o'rgandik:

  • CI vs CD (Integration / Delivery / Deployment farqi — 2.1); arxitektura (workflowjobsteprunneraction — 2.2); YAML anatomiyasi (.github/workflows/*.yml — 2.3).
  • Runner (GitHub-hosted vs self-hosted — 2.4); trigger'lar (push/PR/schedule/manual — 2.5); job'lar (parallel va needs — 2.6); action'lar (uses/with/versiya — 2.7).
  • Secrets/xavfsizlik (GITHUB_TOKEN, repo secrets, OIDC, permissions — 2.8); cache/artifact (tezlik va natija — 2.9); environment/approval (manual gate — 2.10); pipeline/deploy strategiyalari 2.11-bob; reusable/branch protection 2.12-bob.
  • Concurrency (takror run bekor — 2.13); OIDC (parolsiz bulut — 2.14); composite action (step qayta ishlatish — 2.15); deploy strategiyalari (blue-green, canary, rolling — 2.16); rollback (buzuq deploy qaytarish — 2.17); xavfsizlik skani (Dependabot, CodeQL — 2.18); monorepo/badge/boshqa platforma 2.19-bob.

Endi qo'lda deploy'dan 10.1-bobavtomatik pipeline'ga o'tildi: har push tekshiriladi, test qilinadi, qurib serverga chiqariladi — odam aralashuvisiz, ishonchli va tez. Bu — "kod yozaman, lekin uni qo'lda chiqaraman" degan chegarani buzadi: endi konveyer ishlaydi.

Keyingi bob — 10.6-bob: Cloud — AWS (EC2, S3, RDS, Lightsail). Shu paytgacha biz o'z VPS'imizga deploy qildik (DigitalOcean kabi — 10.1). Lekin haqiqiy masshtabda ilovalar bulutda (cloud) ishlaydi — eng kattasi AWS (Amazon Web Services). U yerda EC2 (virtual server), S3 (fayl/object saqlash), RDS (boshqariladigan DB), Lightsail (oddiy VPS) bor. CI/CD pipeline'ing (bu bob) ko'pincha aynan AWS'ga deploy qiladi (OIDC bilan secret'siz — 2.8). Cloud — production deploy'ning standart maydoni.


Foydalanilgan rasmiy/ishonchli manbalar

  • GitHub Docs — "Workflow syntax for GitHub Actions"; "Events that trigger workflows" (docs.github.com/en/actions, 2026)
  • GitHub Docs — "Using secrets in GitHub Actions"; "OpenID Connect (OIDC) hardening"; "Reusing workflows"; "Using concurrency"; "Deployments and environments" (2026)
  • GitHub Docs — "Creating a composite action"; "Choosing the runner for a job" (GitHub-hosted / self-hosted) (2026)
  • actions/checkout@v4, actions/setup-node@v4, actions/cache@v4, actions/upload-artifact@v4, actions/download-artifact@v4 — rasmiy action README'lari
  • docker/build-push-action, docker/login-action, docker/setup-buildx-action (Docker Docs — "GitHub Actions CI"); appleboy/ssh-action (Marketplace)
  • aws-actions/configure-aws-credentials (AWS OIDC bilan autentifikatsiya); AWS Docs — "Configuring OpenID Connect in AWS"
  • GitHub Docs — "Working with the Container registry (GHCR)"; "Managing a branch protection rule"; "Adding a workflow status badge" (2026)
  • GitHub Docs — "About Dependabot version updates"; "About code scanning with CodeQL" (Security — 2026)
  • GitHub Docs — "About deployments" (deployment strategiyalari); Kubernetes/AWS ECS hujjatlari — rolling / blue-green / canary
  • Monorepo: Turborepo va Nx rasmiy hujjatlari — "affected" (faqat o'zgargan paketni build/test)
  • Taqqoslash uchun: GitLab CI/CD (.gitlab-ci.yml), Jenkins (Jenkinsfile) rasmiy hujjatlari

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
10.5-bob: CI/CD — GitHub Actions — Wisar