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 (
.ymlfaylda 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
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 —
maindoim 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)
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>.ymlfaylda 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 — fayllarneeds/artifact orqali uzatiladi). Runner — ishni bajaradigan mashina (GitHub ijaraga beradi — 2.4). Action — qayta ishlatiladigan blok (actions/checkout— kod olish; boshqalar yozgan — sizusesbilan ulaysiz — 2.7). Bu ierarxiyani tushunish — barcha workflow yozishning asosi.
2.3. Workflow YAML anatomiyasi (.github/workflows/*.yml)
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-qiymatWorkflow YAML anatomiyasi — fayl
.github/workflows/papkasida (.ymlyoki.yaml). Asosiy kalitlar:name— workflow nomi (UI'da ko'rinadi, ixtiyoriy);on— qachon ishga tushadi (trigger event — 2.5);jobs— ishlar (kamida bitta); har job ichidaruns-on(qaysi runner — 2.4) vasteps(qadamlar). Step ikki xil:uses(tayyor action — 2.7) yokirun(shell buyruq —|bilan ko'p qatorli). Qadamganameberish 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.ymlfayl paydo bo'lishi bilan GitHub uni avtomatik o'qiydi va "Actions" tab'ida ishga tushiradi.
2.4. Runner — GitHub-hosted vs self-hosted
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-latesteng keng, tez, arzon;windows-latest,macos-latestham 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 uchunubuntu-latest— 99% holatda yetarli (Linux serverga deploy ham Linux runner'da mantiqiy — 10.1).
2.5. Trigger event'lar (push / pull_request / schedule / manual)
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 (branchesbilan faqat ma'lum branch'larga;pathsbilan faqat ma'lum fayllar o'zgarsa;tagsbilan 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 (cronsintaksisi, masalan"0 3 * * *"— har kuni 03:00 UTC'da — kechasi to'liq test);workflow_dispatch— qo'lda ishga tushirish (GitHub UI'da "Run workflow" tugmasi, ixtiyoriyinputsbilan — masalan qaysi muhitga deploy qilish). Ikki muhim nuqta: (1) fork'dan kelgan PR'da secret'lar berilmaydi (begona kod paroliga yetmasin — xavfsizlik); (2)crondoim 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)
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):
lintvatestbir-birini kutmay ishga tushadi. Sequential (ketma-ket) qilish uchunneeds:deploy: needs: [lint, test]—deployfaqatlintvatestmuvaffaqiyatli o'tgach ishlaydi (ikkalasi fail bo'lsa —deployishlamaydi, butun pipeline qizil). Bu — bog'liqlik grafi (dependency graph): GitHub qaysi job qaysidan keyin kelishinineeds'dan tushunadi. Eng muhim tushuncha: har job — toza, alohida mashina 2.2-bob.deployjob'itestjob'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'dadist/yo'q"). Job'lar grafi — pipeline'ning skeleti.
2.7. Action'lar — marketplace, uses, with, versiya
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).
usesbilan ulanadi:actions/checkout@v4—actions(ega — GitHub rasmiy),checkout(nom),@v4(versiya). Action'ga parametr —withbloki (masalansetup-node'ganode-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) —@mainishlatma (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)
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 yozmaSecret — 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 (masalansecrets.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);permissionsbloki bilan huquqni cheklash kerak (eng kam imtiyoz — 10.1: 2.4 — masalancontents: read, push kerak bo'lsapackages: 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 qachonechoqilma, log'ga chiqarma, kodga yozma. Workflow.ymlfayl ochiq (repo'da ko'rinadi) — unda faqatsecrets.Xhavolasi, qiymat emas 14.5-bob.
2.9. Caching va artifact (tezlik va natija)
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/saqlashCache va artifact — ikki xil maqsad (aralashtirma): Cache (
actions/cache@v4yokisetup-node'ningcache: "npm") — tezlik uchun: har run'danpm install~2 daqiqa (node_modulesqayta yuklanadi); kesh bilan bir marta yuklab saqlanadi, keyingi run tayyor oladi (sekundlar). Kesh kalit (key) bilan ishlaydi — odatdapackage-lock.jsonhash'idan (lockfile o'zgarmasa — keshdan; o'zgarsa — yangi yuklab qayta keshlaydi — 5.2).setup-node'ningcache: "npm"buni avtomatik qiladi (eng oson). Artifact (upload-artifact/download-artifact) — natija uzatish/saqlash: build jobdist/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,.apkfayl). Qisqasi: cache = qayta yuklamaslik (tezlik), artifact = job'lararo/odam uchun natija.
2.10. Environment va approval (manual gate)
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'gaenvironment: productionqo'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 — faqatmain'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
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 + buyruq —appleboy/ssh-actionbilan serverdagit pull && systemctl restartyokidocker compose up10.1-bob; (B) Docker pull — image registry'ga push qilingach, serverdocker compose pull && up -dqiladi (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
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: inheritbilan 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 yangimainbilan). 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
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:
concurrencybloki bilangroup(odatdagithub.ref— branch/PR bo'yicha) vacancel-in-progress: true— shu guruhda yangi run boshlanganda eski, tugamagan run avtomatik bekor qilinadi, faqat oxirgi commit tekshiriladi. Muhim istisno: deploy job'idacancel-in-progress: falseqo'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
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: writemajburiy); (2) bulut GitHub'ni "ishonchli identity provider" deb tan oladi; (3)aws-actions/configure-aws-credentialsbilan 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
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.ymlfaylidausing: 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'darun:uchunshellmajburiy (shell: bash). Reusable workflow 2.12-bob — butun job(lar)ni qayta ishlatadi (on: workflow_call),uses: ...reusable.ymlbilan 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)
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
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'lsinRollback — production buzilganda oldingi ishlaydigan versiyaga tez qaytish. Buning uchun eng muhim shart — har deploy izlanadigan (immutable) versiya bilan bo'lishi:
image:latestemas,image:${{ github.sha }}(aniq commit) — shunda rollback = "oldingi SHA'ni qayta yoqish". Usullar: (1) Docker teg — serverda oldingi image tegi bilandocker compose up -d; (2) Git revert —git 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
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 yoqingXavfsizlik 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.ymlfaylida 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'dagithub/codeql-action/init+analyzebilan 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
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):

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 xilMonorepo — bitta repo'da bir nechta paket/servis (masalan
apps/api,apps/web,packages/ui). Bu yerdapathsfiltr hal qiluvchi: faqatapps/api/**o'zgarsaapiCI'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.svghavolasi) — 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
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)
# .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" belgiMisol 2 — Matrix build (ko'p Node versiya — parallel)
# 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)
# 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)
# 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 qiladiMisol 5 — Docker image qurish va GHCR'ga push (10.3, 10.4)
# 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)
# 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)
# 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)
# 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)
# === .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)
# 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)
# 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)
# === .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)
# 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)
# 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)
# === .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
uses: actions/checkout@main (har o'zgarishda buzilishi mumkin — 2.7)
uses: actions/checkout@v4 (versiya qadalgan — barqaror)2) Secret bilan ishlash
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
npm install (lockfile yangilanadi, har run boshqa versiya — 5.2)
npm ci (lockfile'dan AYNAN, takrorlanadigan, tez — CI uchun)4) Job'lar orasida fayl
build job dist/ qurdi, deploy job ishlatadi (toza mashina — KO'RMAYDI — 2.6)
upload-artifact (build) download-artifact (deploy) — 2.95) Test va deploy tartibi
deploy avval, test keyin (buzuq kod chiqib ketadi — 2.11)
needs: [test] — test o'tgach deploy (CI gate — 2.6)6) Production deploy
har push avtomatik production'ga (xato darrov foydalanuvchida — 2.10)
environment: production + required reviewers (approval gate)7) GITHUB_TOKEN huquqi
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_KEYsecret). - Docker 10.3-bob: CI image quradi (
docker/build-push-action). - Docker Compose 10.4-bob: server
docker compose pull && up -dbilan 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_requesttrigger, 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 (
@v4yoki SHA —@mainemas — barqarorlik/xavfsizlik — 2.7). npm ci(lockfile'dan aniq, takrorlanadigan —npm installemas — 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-allemas — 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: falsebilan to'liq qamrov — 2.6). - Reusable workflow (ko'p repo'da takrorlama — DRY — 2.12, 15.1).
paths/concurrencyfiltr (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)
- CI workflow:
pull_request'da lint + test + build ishlasin (Misol 1, 7, 2.5). - Matrix: test'ni Node 20 va 22'da parallel sina (
fail-fast: false— Misol 2, 2.6). - Caching:
setup-node cache:"npm"bilan tezlashtir (Misol 1, 2.9). - Docker:
main'ga push'da image qurib GHCR'ga push (packages: write— Misol 5, 10.3). - Secrets:
SSH_PRIVATE_KEY,SERVER_HOSTrepo secrets'da; hech qayerda ochiq emas 2.8-bob. - Deploy:
appleboy/ssh-actionbilan serverdadocker compose pull && up -d(Misol 6, 8, 10.4). - needs: deploy faqat lint+test o'tgach (sequential — Misol 8, 2.6).
- Environment:
productionmuhitiga required reviewers (approval gate — Misol 10, 2.10). - Branch protection:
main'da CI required + PR review (qizil = merge yo'q — 2.12, 4.3). - Manual deploy:
workflow_dispatchbilan 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.
-
mainpush'da Docker image GHCR'ga push bo'ladi. - Secret'lar hech qayerda ochiq emas (faqat
secrets.Xhavola). - 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_dispatchbilan 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-bob — avtomatik 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'laridocker/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!