CI/CD là viết tắt của Continuous Integration và Continuous Deployment (hoặc Continuous Delivery). Đây là phương pháp tự động hóa quy trình build, test, và deploy code thay vì làm thủ công. CI/CD giúp teams ship code nhanh hơn, với fewer errors, và more confidence.

CI/CD không chỉ là tools — đó là culture và practice giúp developers collaborate hiệu quả hơn, detect bugs sớm, và deliver value liên tục đến users.

Continuous Integration (CI)

Continuous Integration là practice mà developers merge code changes thường xuyên (multiple times daily) vào main branch, với automated builds và tests chạy để verify changes.

• Main/Trunk-based development: Developer merge vào main branch thường xuyên
• Automated builds: Mỗi commit trigger automatic build
• Automated tests: Unit tests, integration tests chạy tự động
• Fast feedback: Developers biết build pass/fail trong minutes

Continuous Delivery vs Continuous Deployment

Continuous Delivery

Code changes tự động được prepared cho release to production. Deployment đến production vẫn require manual approval. Đảm bảo code luôn sẵn sàng deploy nhưng không tự động deploy.

Continuous Deployment

Every change that passes tests được tự động deployed to production. Không có manual intervention. Requires strong automation và monitoring để prevent bad releases.

So sánh

CI/CD Pipeline Stages

1. Source Code Management

Trigger pipeline when code pushed to repository. Support GitHub, GitLab, Bitbucket. Pipeline configured in code (.github/workflows, .gitlab-ci.yml).

2. Build Stage

• Compile code, resolve dependencies
• Generate artifacts (binaries, Docker images)
• Fail fast if build fails

3. Test Stage

• Unit tests: Fast, isolated tests
• Integration tests: Test components working together
• E2E tests: Full application flow (slower)
• Security scans: SAST, dependency check

4. Deploy Stage

• Staging deployment: Review changes before production
• Production deployment: Blue-green, canary, hoặc rolling
• Rollback capability: Automatic nếu health checks fail

CI/CD Tools

GitHub Actions

name: CI Pipeline

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run build
      - run: npm test

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Server
        uses: appleboy/ssh-action@master
        with:
          host: \${{ secrets.SERVER_HOST }}
          username: ubuntu
          key: \${{ secrets.SSH_KEY }}
          script: |
            docker-compose down
            docker-compose pull
            docker-compose up -d

GitLab CI

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:18-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  image: node:18-alpine
  script:
    - npm test

deploy:
  stage: deploy
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker push registry.com/myapp:$CI_COMMIT_SHA
  environment:
    name: production
  only:
    - main

Jenkins

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'npm ci'
                sh 'npm run build'
            }
        }
        stage('Test') {
            steps {
                sh 'npm test'
            }
            post {
                always {
                    junit '**/test-results/*.xml'
                }
            }
        }
        stage('Deploy') {
            when { branch 'main' }
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
                sh 'docker push registry.com/myapp:${BUILD_NUMBER}'
            }
        }
    }
}

Docker trong CI/CD

Docker phổ biến trong CI/CD vì consistent environments từ local đến production:

docker build -t myapp:$CI_COMMIT_SHA .
docker run --rm myapp:$CI_COMMIT_SHA npm test
docker push myapp:$CI_COMMIT_SHA
docker-compose -f docker-compose.prod.yml up -d

Deployment Strategies

Rolling Deployment

Thay thế instances từng cái một. Simple, no downtime. Con: Mixed versions during rollout.

kubectl rolling-update myapp --image=myapp:v2

Blue-Green Deployment

Maintain two identical environments. Traffic switch từ blue (current) sang green (new). Instant rollback by switching back.

docker-compose -f docker-compose.green.yml up -d
# Switch traffic (update load balancer)
# If issues, switch back to blue
# If good, shutdown blue

Canary Deployment

Route small % traffic đến new version, gradually increase. Allows real-world testing với minimal risk.

kubectl set image deployment/myapp myapp=v2
kubectl patch service myapp -p '{"spec":{"selector":{"version":"v2"}}}'

Testing Strategies

Monitoring CI/CD Pipeline

CI/CD Best Practices

• Keep pipeline fast: Run unit tests first, parallelize jobs
• Fail fast: Early detection saves time
• Pipeline as code: Version control pipeline configs
• Immutable artifacts: Once built, don’t modify
• Self-contained builds: No external dependencies at build time
• Automate everything: Manual steps create bottlenecks

Security in CI/CD

• SAST: Static Application Security Testing (code scan)
• Dependency scan: Check for known vulnerabilities
• Container scan: Trivy, Snyk, Clair
• DAST: Dynamic Application Security Testing (run against live app)
• Secrets management: GitHub Secrets, Vault, AWS Secrets Manager

FAQ – Các câu hỏi thường gặp

• CI/CD khác gì với DevOps? DevOps là culture và set of practices cho software development và operations. CI/CD là technical implementation của DevOps — automation tools và processes. CI/CD là subset của DevOps.
• Khi nào nên deploy to production? Deploy when: all tests pass, code reviewed, staging verified, rollback plan ready. Continuous Deployment tự động deploy all passing changes. Continuous Delivery requires manual approval before production.
• Làm sao handle database migrations in CI/CD? Database migrations cần careful handling: separate migration job, test on copy of production data, have rollback strategy. Tools: Flyway, Liquibase. Migrations should be backward-compatible.
• Test coverage bao nhiêu là đủ? Industry standard often cited as 80%, but quality matters more than quantity. Focus on critical paths và business logic coverage. 100% coverage không guarantee bug-free code.
• Rollback strategy như thế nào? Rolling back: re-deploy previous version (docker tag, Helm rollback, K8s rollout undo). Automated rollback: health check failures trigger rollback. Blue-green: instant switch back. Feature flags: disable flag instant.