1. CI va CD nima — qisqacha va aniq

CI (Continuous Integration) — dasturchilar yozgan kodni tez-tez (har push/merge) avtomatik test va build jarayonidan o‘tkazish. Maqsad — integratsion muammolarni erta aniqlash va jamoaviy ishni silliq qilish.

CD ikki ma'noda ishlatiladi: Continuous Delivery (deploy uchun tayyor holat) va Continuous Deployment (testdan oʻtgan har commit avtomatik prod-ga chiqadi). Oddiy qilib aytganda: CI test qiladi, CD esa deploy qiladi.

2. CI/CD qiymati va biznes foydasi

• Tezroq iteratsiya: yangi xususiyatlar tezroq foydalanuvchiga yetadi.
• Xatolarni erta aniqlash: unit va integration testlar production oldidan ishlaydi.
• Ishonchli deploy: avtomatlashtirish inson xatosini kamaytiradi.
• MTTR pasayadi: avtomatik rollback va monitoring tufayli tiklanish tezlashadi.
• Jamoa samaradorligi oshadi: code review + pipeline kombinatsiyasi tufayli.

3. Arxitektura va asosiy komponentlar

CI/CD ekotizimi odatda quyidagi elementlardan tashkil topadi:

• VCS: GitHub / GitLab / Bitbucket
• CI server: GitHub Actions, GitLab CI, Jenkins, CircleCI
• Artifact registry: Docker Hub, GitHub Container Registry, Nexus
• IaC: Terraform, Pulumi
• Config management: Ansible, Chef, Puppet
• Orchestration: Kubernetes yoki Docker Compose (kichik loyihalar uchun)
• Monitoring & Logging: Prometheus, Grafana, ELK/EFK, Sentry
• Secrets management: Vault, AWS Secrets Manager, GitHub Secrets

4. Pipeline dizayni va strategiyalar

Branching modeli

Ikki mashhur yondashuv:

• Git Flow — murakkab release jarayonlari uchun.
• Trunk-based development — tez iteratsiyalar va kichik feature branchlar uchun tavsiya qilinadi.

Men tavsiya qilaman: trunk-based + short-lived feature branches.

Muhitlar (Environments)

Har bir muhitga alohida konfiguratsiya va secretlar kerak: dev, staging, prod. Hech qachon secrets’ni repo ichiga qoʻymang.

Test strategiyasi

• Unit tests: har pushda majburiy.
• Integration tests: PR yoki staging-ga push qadamida.
• E2E tests: staging deploydan keyin.

5. Amaliy misol: Node.js ilovasini CI/CD orqali deploy

Quyidagi misolda GitHub Actions orqali test→build→image→server deploy qadamlarini koʻramiz. Bu real loyihada tez ishlatilishi mumkin bo‘lgan yondashuv.

Dockerfile (multi-stage)

<!-- Dockerfile -->
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:18-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/index.js"]

GitHub Actions workflow

name: CI/CD

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 18
      - name: Install deps
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Build
        run: npm run build

  build-and-push-image:
    needs: build-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2
      - name: Login to registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GHCR_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository_owner }}/myapp:${{ github.sha }}

  deploy:
    needs: build-and-push-image
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to server via SSH
        uses: appleboy/ssh-action@v0.1.7
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            docker pull ghcr.io/${{ github.repository_owner }}/myapp:${{ github.sha }}
            docker stop myapp || true
            docker rm myapp || true
            docker run -d --name myapp -p 3000:3000 \
              -e NODE_ENV=production \
              ghcr.io/${{ github.repository_owner }}/myapp:${{ github.sha }}

Eslatma: secrets.GHCR_TOKEN, SERVER_HOST, SERVER_USER, SERVER_SSH_KEY — GitHub repo settings → Secrets ga qoʻyiladi.

Server tomoni (Docker Compose)

version: "3.8"
services:
  myapp:
    image: ghcr.io/yourorg/myapp:latest
    ports:
      - "3000:3000"
    restart: unless-stopped
    environment:
      - NODE_ENV=production

Bu yondashuv kichik va oʻrta loyihalar uchun yetarli. Katta infrada Ansible yoki Terraform bilan birga ishlash tavsiya etiladi.

6. Jenkins va Kubernetes bilan CI/CD

Katta loyihalarda Jenkins yoki boshqa orchestratorlar bilan Kubernetes kombinatsiyasi keng qoʻllanadi. Quyida soddalashtirilgan Jenkinsfile misoli:

pipeline {
  agent any
  environment {
    REGISTRY = "ghcr.io/yourorg"
    IMAGE = "${REGISTRY}/myapp:${env.BUILD_NUMBER}"
  }
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
    stage('Build & Test') {
      steps {
        sh 'npm ci'
        sh 'npm test'
        sh 'npm run build'
      }
    }
    stage('Build Image') {
      steps {
        sh "docker build -t ${IMAGE} ."
        withCredentials([string(credentialsId: 'GHCR_TOKEN', variable: 'TOKEN')]) {
          sh "echo $TOKEN | docker login ghcr.io -u youruser --password-stdin"
        }
        sh "docker push ${IMAGE}"
      }
    }
    stage('Deploy to K8s') {
      steps {
        withCredentials([file(credentialsId: 'KUBECONFIG', variable: 'KUBE_CONFIG')]) {
          sh 'kubectl --kubeconfig=$KUBE_CONFIG set image deployment/myapp myapp=${IMAGE}'
        }
      }
    }
  }
  post {
    failure {
      mail to: 'team@company.uz', subject: "Build failed: ${env.JOB_NAME}", body: "Build ${env.BUILD_NUMBER} failed"
    }
  }
}

Kubernetes deployni kubectl set image yoki helm upgrade --install yordamida boshqarish mumkin. Deploy tugagach kubectl rollout status bilan muvaffaqiyatni tekshirish muhim.

7. Serverlarda konfiguratsiya boshqaruvi: Ansible + Docker

Katta infrada serverlarni qoʻlda boshqarish nojoʻya. Ansible playbook yordamida docker image pull va containerni yangilashni avtomatlashtirish mumkin:

- hosts: app_servers
  become: true
  tasks:
    - name: Pull latest Docker image
      community.docker.docker_image:
        name: ghcr.io/yourorg/myapp
        tag: "{{ image_tag }}"
        source: pull

    - name: Stop and remove existing container
      community.docker.docker_container:
        name: myapp
        state: absent

    - name: Run new container
      community.docker.docker_container:
        name: myapp
        image: ghcr.io/yourorg/myapp:{{ image_tag }}
        restarted: true
        ports:
          - "3000:3000"
        env:
          NODE_ENV: production

Bu playbook CI job orqali chaqirilishi yoki Ansible Tower/Jenkins orqali boshqarilishi mumkin.

8. Deploy strategiyalari: rolling, blue–green, canary va rollback

Rolling update

Kubernetes va Docker Swarm rolling update-ni qoʻllab-quvvatlaydi — yangi podlar asta-sekin almashtiriladi.

Blue–Green

Ikki muhit: blue (joriy) va green (yangi). Trafikni load balancer orqali green ga oʻtkazib, muammolar boʻlsa qaytarish oson.

Canary

Yangi versiyani avval kichik auditoriyaga chiqarish — traffic split va monitoring bilan qadam-qadam kengaytirish.

Rollback

• Kubernetes: kubectl rollout undo deployment/myapp
• Docker: eski image tag bilan qayta docker run
• CI: artifact’larni arxivlab qoʻyish — kerak boʻlsa eski versiyani qayta tiklash

9. Security, monitoring va observability

Security

• SCA (Software Composition Analysis): Dependabot, Snyk, Trivy orqali vuln skanerlash.
• Secrets management: Vault, AWS Secrets Manager, GitHub Secrets.
• Immutable images: image’ni modify qilmasdan, har build uchun yangi tag ishlatish.
• RBAC va minimal huquqlar (Kubernetes).
• Image signing va scanner.

Monitoring & Observability

• Metrics: Prometheus + Grafana (CPU, memory, latency).
• Tracing: Jaeger yoki OpenTelemetry.
• Error tracking: Sentry.
• Logs: EFK (Elasticsearch, Fluentd, Kibana) yoki Loki + Grafana.
• Health checks: liveness va readiness probe (Kubernetes)

10. Performance va pipeline optimallashtirish

• Cache: npm/yarn cache, docker layer cache (buildx cache) — build vaqtini kamaytiradi.
• Parallel jobs: testlarni parallelga bo‘lish orqali vaqtni qisqartirish.
• Incremental builds: monorepo uchun turborepo yoki nx ishlatish.
• Artifact reuse: testdan o'tgan build artifact’larni qayta ishlatish.
• Agent sizing: build agentlarni to‘g‘ri tanlash (CPU/RAM).

11. Checklist va troubleshooting

Pre-deploy checklist

• Testlar passed ✅
• Security scan done ✅
• Migration scripts tayyor ✅
• Backup mavjud ✅
• Monitoring va alertlar sozlangan ✅

Post-deploy checklist

• Health checks OK ✅
• Error rate normal ✅
• Latency tekshirildi ✅
• Rollback reja aniq ✅

Troubleshooting

1. kubectl logs, docker logs bilan loglarni tekshir.
2. kubectl describe pod — eventlarni ko‘r.
3. Resource limitlar (CPU/Memory) yetishmayapti yoki yo‘qmi tekshir.
4. Network — firewall yoki SELinux muammolari.
5. DB migratsiyalar to‘liq bajarilganmi?
6. Agar kerak bo‘lsa rollback qiling.