YouTube  Qo'shilish
Bosh sahifa Wiki CI/CD

CI/CD

CI/CD — dasturiy ta’minotni ishlab chiqish, tekshirish va serverga joylash jarayonlarini avtomatlashtirish yondashuvi. CI/CD inglizcha Continuous Integration va Continuous Delivery yoki Continuous Deployment so‘zlarining qisqartmasi hisoblanadi.

CI/CD yordamida kod o‘zgarishlari avtomatik tekshiriladi, build qilinadi va kerakli muhitga deploy qilinadi. Bu jarayon dasturlashda tezkor, tartibli va takrorlanadigan release oqimini yaratadi.

Vazifasi

CI/CD kod yozishdan production muhitga chiqarishgacha bo‘lgan jarayonlarni avtomatlashtirish uchun ishlatiladi.

CI/CD quyidagi vazifalarni bajaradi:

  • kod o‘zgarishlarini avtomatik tekshirish;
  • testlarni ishga tushirish;
  • lint va format tekshiruvlarini bajarish;
  • build jarayonini avtomatlashtirish;
  • Docker image yaratish;
  • security scan bajarish;
  • staging yoki production serverga deploy qilish;
  • migration ishga tushirish;
  • service’larni restart qilish;
  • release jarayonini boshqarish.

Masalan, main branchga yangi commit push qilinganda testlar ishga tushib, build tayyorlanib, serverga deploy bajarilishi mumkin.

CI nima?

CI — Continuous Integration, ya’ni uzluksiz integratsiya. Bu jarayonda dasturchilar yozgan kodlarini tez-tez umumiy repositoryga qo‘shadi va har bir o‘zgarish avtomatik tekshiruvlardan o‘tadi.

CI jarayonida odatda quyidagilar bajariladi:

  • repositoryga push qilinadi;
  • pipeline ishga tushadi;
  • dependency’lar o‘rnatiladi;
  • testlar bajariladi;
  • lint tekshiriladi;
  • type checking bajariladi;
  • build qilinadi;
  • natija pull request yoki commit yonida ko‘rsatiladi.

CI asosiy branchga xatoli kod qo‘shilib ketmasligini kamaytirishga yordam beradi.

CD nima?

CD ikki xil ma’noda ishlatiladi:

  • Continuous Delivery — kod avtomatik tekshiriladi va deployga tayyor holatga keltiriladi;
  • Continuous Deployment — kod tekshiruvlardan o‘tgach avtomatik production yoki boshqa muhitga deploy qilinadi.

Continuous Delivery’da deploy jarayoni qo‘lda tasdiqlanishi mumkin. Continuous Deployment’da esa deploy to‘liq avtomatik bajariladi.

CI/CD qanday ishlaydi?

CI/CD repositorydagi hodisalarga bog‘langan holda ishlaydi. Masalan, push, pull request yoki tag yaratilganda pipeline ishga tushadi.

Oddiy jarayon:

  • dasturchi kod yozadi;
  • o‘zgarish commit qilinadi;
  • branch remote repositoryga push qilinadi;
  • CI/CD pipeline ishga tushadi;
  • test, lint va build bajariladi;
  • natijalar platformada ko‘rsatiladi;
  • kerak bo‘lsa deploy bajariladi;
  • serverdagi ilova yangilanadi.

Bu jarayon har safar bir xil tartibda bajarilgani uchun deployment nazorat qilinadigan holatda bo‘ladi.

Pipeline

Pipeline — CI/CD jarayonida ketma-ket yoki parallel bajariladigan bosqichlar to‘plami. Pipeline kodni tekshirishdan deploygacha bo‘lgan amallarni o‘z ichiga oladi.

Pipeline bosqichlari:

Masalan, backend loyihada pipeline avval testlarni bajaradi, keyin Docker image yaratadi va yakunda serverga deploy qiladi.

Job

Job — pipeline ichidagi alohida bajariladigan vazifa. Har bir job ma’lum buyruqlar to‘plamini bajaradi.

Job misollari:

Joblar ketma-ket yoki parallel bajarilishi mumkin.

Step

Step — job ichidagi alohida qadam. Step odatda bitta buyruq yoki bitta tayyor action bajaradi.

Step misollari:

  • repositoryni yuklash;
  • Node.js o‘rnatish;
  • Python environment tayyorlash;
  • package o‘rnatish;
  • test buyrug‘ini ishga tushirish;
  • build qilish;
  • deploy script bajarish.

Pipeline bir nechta jobdan, job esa bir nechta stepdan iborat bo‘ladi.

Trigger

Trigger — CI/CD pipeline qachon ishga tushishini belgilaydigan hodisa.

Keng ishlatiladigan triggerlar:

Masalan, main branchga push bo‘lganda production deploy pipeline ishga tushishi mumkin.

Build

Build — kodni ishga tayyor holatga keltirish jarayoni. Frontend loyihalarda build odatda static fayllar yaratadi. Backend loyihalarda esa package, image yoki executable hosil qilishi mumkin.

Build jarayonida quyidagilar bajarilishi mumkin:

Build natijasi deploy jarayonida ishlatiladi.

Test

CI/CD pipeline’da testlar kod to‘g‘ri ishlashini tekshirish uchun avtomatik bajariladi.

Test turlari:

Masalan, pull request ochilganda testlar avtomatik ishlaydi va natija reviewerga ko‘rinadi.

Lint

Lint — kod yozilish uslubi va ayrim xatoliklarni avtomatik tekshirish jarayoni.

Lint quyidagilarni aniqlashi mumkin:

  • noto‘g‘ri format;
  • ishlatilmagan variable;
  • syntax muammolari;
  • import tartibi;
  • loyiha coding style qoidalari;
  • ehtimoliy xatoliklar.

JavaScript loyihalarda ESLint, Python loyihalarda Ruff yoki Flake8 kabi vositalar ishlatilishi mumkin.

Type checking

Type checking — koddagi type mosligini tekshirish jarayoni. TypeScript, Python typing yoki boshqa statik tekshiruv vositalari orqali bajarilishi mumkin.

Type checking quyidagilarni aniqlaydi:

  • noto‘g‘ri argument type’i;
  • noto‘g‘ri return type;
  • mavjud bo‘lmagan property;
  • interface yoki type mos kelmasligi;
  • API response type xatolari.

TypeScript loyihalarda tsc --noEmit kabi buyruqlar CI’da ishlatilishi mumkin.

Artifact

Artifact — CI/CD pipeline natijasida hosil bo‘ladigan fayl yoki paket. Artifact keyingi bosqichlarda yoki deployment jarayonida ishlatilishi mumkin.

Artifact misollari:

Artifact pipeline natijasini saqlash va keyingi joblarga uzatish uchun ishlatiladi.

Deployment

Deployment — tayyor kodni server, hosting, cloud yoki boshqa runtime muhitga joylash jarayoni.

Deployment jarayonida quyidagilar bajarilishi mumkin:

CI/CD deployment jarayonini avtomatlashtiradi va takrorlanadigan holatga keltiradi.

Environment

Environment — ilova ishlaydigan muhit. CI/CD’da turli muhitlar uchun alohida pipeline yoki deploy bosqichlari bo‘lishi mumkin.

Asosiy environment turlari:

  • development — dasturchilar ishlaydigan muhit;
  • testing — testlar bajariladigan muhit;
  • staging — productionga yaqin sinov muhiti;
  • production — foydalanuvchilar ishlatadigan haqiqiy muhit.

Masalan, develop branch staging muhitga, main branch production muhitga deploy qilinishi mumkin.

Staging

Staging — productionga o‘xshash test muhiti. Staging’da kod haqiqiy foydalanuvchilarga chiqishidan oldin tekshiriladi.

Staging muhitda quyidagilar sinovdan o‘tadi:

Staging productiondan oldingi nazorat bosqichi sifatida ishlatiladi.

Production

Production — foydalanuvchilar real ishlatayotgan muhit. Production muhitdagi ilova barqaror, xavfsiz va ishlashga tayyor holatda bo‘lishi kerak.

Production deployment’da quyidagilar muhim hisoblanadi:

CI/CD productionga deploy jarayonini nazoratli va avtomatik bajarishga yordam beradi.

Rollback

Rollback — yangi deploymentda muammo chiqsa, ilovani oldingi barqaror holatga qaytarish jarayoni.

Rollback quyidagi holatlarda ishlatiladi:

  • deploydan keyin xatolik chiqsa;
  • API ishlamay qolsa;
  • frontend buzilsa;
  • migration muammo bersa;
  • performance keskin pasaysa;
  • productionda kritik xato aniqlansa.

Rollback deployment strategiyasining muhim qismi hisoblanadi.

Secrets

Secrets — CI/CD pipeline ichida ishlatiladigan maxfiy qiymatlar. Secrets kod ichida ochiq yozilmaydi, platforma sozlamalarida saqlanadi.

Secrets ichida quyidagilar bo‘lishi mumkin:

Pipeline secrets qiymatlarini kerakli vaqtda environment variable sifatida ishlatadi.

Environment variables

Environment variables — ilova yoki pipeline sozlamalarini tashqi qiymatlar orqali boshqarish usuli.

Environment variables quyidagilar uchun ishlatiladi:

CI/CD jarayonida har bir muhit uchun alohida environment variable bo‘lishi mumkin.

Runner

Runner — CI/CD joblarini bajaradigan server yoki container muhiti. Pipeline ichidagi buyruqlar runner ustida bajariladi.

Runner turlari:

  • hosted runner;
  • self-hosted runner;
  • Linux runner;
  • Windows runner;
  • macOS runner;
  • Docker runner.

Masalan, GitHub Actions’da ubuntu-latest runneri pipeline buyruqlarini Linux muhitida bajaradi.

GitHub Actions

GitHub Actions — GitHub ichida CI/CD workflow yaratish uchun ishlatiladigan xizmat.

GitHub Actions orqali quyidagilar bajarilishi mumkin:

Workflow fayllari odatda repository ichidagi .github/workflows papkasida saqlanadi.

GitLab CI

GitLab CI — GitLab platformasidagi CI/CD tizimi. U .gitlab-ci.yml fayli orqali sozlanadi.

GitLab CI quyidagi vazifalarda ishlatiladi:

GitLab CI GitLab repositorylari bilan chuqur bog‘langan holda ishlaydi.

Docker va CI/CD

Docker CI/CD jarayonida ilovani bir xil muhitda build qilish va ishga tushirish uchun ishlatiladi.

Docker bilan CI/CD quyidagilarni bajarishi mumkin:

Masalan, backend API Docker image sifatida build qilinib, serverda container ko‘rinishida ishga tushirilishi mumkin.

Docker registry

Docker registry — Docker image’larni saqlash uchun ishlatiladigan xizmat.

Registry misollari:

CI/CD pipeline Docker image yaratib, uni registry’ga yuborishi va deployment vaqtida shu image’dan foydalanishi mumkin.

Migration

Database bilan ishlaydigan loyihalarda deployment jarayonida migration bajarilishi mumkin. Migration database tuzilmasidagi o‘zgarishlarni qo‘llaydi.

Migration orqali quyidagilar bajariladi:

  • yangi jadval yaratish;
  • ustun qo‘shish;
  • index yaratish;
  • relation qo‘shish;
  • ustun turini o‘zgartirish;
  • constraint qo‘shish.

CI/CD’da migration odatda deploy jarayonining alohida bosqichi sifatida bajariladi.

Health check

Health check — deploymentdan keyin ilova ishlayotganini tekshirish jarayoni.

Health check quyidagilarni tekshirishi mumkin:

Health check deployment muvaffaqiyatli yakunlanganini aniqlashda ishlatiladi.

Blue-green deployment

Blue-green deployment — ikki alohida muhit orqali deploy qilish strategiyasi. Bitta muhit production traffic qabul qiladi, ikkinchi muhitda yangi versiya tayyorlanadi.

Jarayon:

  • blue muhitda eski versiya ishlaydi;
  • green muhitga yangi versiya deploy qilinadi;
  • green muhit tekshiriladi;
  • traffic green muhitga o‘tkaziladi;
  • muammo chiqsa traffic blue muhitga qaytariladi.

Bu strategiya downtime va rollback xavfini kamaytirish uchun ishlatiladi.

Rolling deployment

Rolling deployment — yangi versiyani serverlar yoki containerlarga bosqichma-bosqich chiqarish strategiyasi.

Rolling deployment’da:

  • barcha instance’lar birdan yangilanmaydi;
  • bir qismi yangi versiyaga o‘tadi;
  • health check bajariladi;
  • keyingi instance’lar yangilanadi;
  • eski va yangi versiya vaqtincha birga ishlashi mumkin.

Bu usul katta tizimlarda uzluksiz yangilanish uchun ishlatiladi.

Manual approval

Manual approval — CI/CD pipeline’da ayrim bosqichlarni qo‘lda tasdiqlash mexanizmi.

Manual approval quyidagi holatlarda ishlatiladi:

  • production deploydan oldin;
  • release chiqarishdan oldin;
  • migration xavfli bo‘lsa;
  • muhim branchga deploy qilinayotganda;
  • enterprise jarayonlarda tasdiq talab qilinganda.

Bu bosqich Continuous Delivery yondashuvida ko‘p uchraydi.

Pipeline failure

Pipeline failure — CI/CD jarayonidagi bosqichlardan biri xato bilan tugagan holat.

Pipeline failure sabablari:

Pipeline xato bo‘lsa, deployment to‘xtashi yoki pull request merge qilinmasligi mumkin.

Notification

CI/CD tizimlari pipeline natijalari haqida bildirishnoma yuborishi mumkin.

Notification kanallari:

Bildirishnomalarda test holati, deploy natijasi, xatolik yoki release haqida ma’lumot bo‘lishi mumkin.

CI/CD va pull request

Pull request ochilganda CI pipeline avtomatik ishlashi mumkin. Bu asosiy branchga qo‘shilishdan oldin kod tekshirilishini ta’minlaydi.

Pull request pipeline quyidagilarni bajarishi mumkin:

Natijalar pull request sahifasida ko‘rinadi va reviewerlar qaror qabul qilishda foydalanadi.

CI/CD va branch

CI/CD pipeline branch nomi yoki branch turiga qarab turlicha ishlashi mumkin.

Misollar:

  • feature/* branchlarda faqat test va lint ishlaydi;
  • develop branch staging muhitga deploy qilinadi;
  • main branch production muhitga deploy qilinadi;
  • release/* branchlarda release build yaratiladi;
  • tag yaratilganda release pipeline ishga tushadi.

Branch asosidagi pipeline loyiha jarayonini avtomatlashtirishda keng ishlatiladi.

CI/CD va xavfsizlik

CI/CD jarayoni kod, server va maxfiy qiymatlar bilan ishlagani uchun xavfsizlik muhim hisoblanadi.

CI/CD xavfsizligida quyidagilar uchraydi:

  • secrets’ni kodga yozmaslik;
  • runner ruxsatlarini cheklash;
  • dependency scan;
  • container image scan;
  • branch protection;
  • manual approval;
  • audit log;
  • deploy kalitlarini himoyalash;
  • minimal permission.

CI/CD pipeline production tizimga ta’sir qilishi mumkin bo‘lgan avtomatlashtirilgan jarayon hisoblanadi.

Dasturlashdagi o‘rni

CI/CD zamonaviy dasturlashda kodni tez, tartibli va nazoratli chiqarish uchun ishlatiladigan muhim jarayondir. U Git repository, testlar, build, deployment va monitoring bilan bog‘liq ishlaydi.

CI/CD quyidagi joylarda qo‘llanadi:

CI/CD kod yozish, tekshirish va serverga joylash jarayonlarini avtomatlashtirib, dasturiy ta’minot ishlab chiqish siklini tezlashtiradi.

Bog‘liq tushunchalar

Git, GitHub, GitHub Actions, GitLab CI, Repository, Commit, Branch, Pull request, Docker, Deployment, DevOps, Server