Tài liệu CI/CD

1. CI/CD là gì?

CI/CD là quy trình tự động hóa trong phát triển phần mềm, giúp code từ lúc developer commit lên Git có thể được kiểm tra, build, test, đóng gói, triển khai lên môi trường test/UAT/production một cách nhanh chóng và an toàn.

CI/CD gồm 2 phần chính:

• CI - Continuous Integration: Tích hợp liên tục. Mỗi khi developer push code lên Git, hệ thống tự động chạy kiểm tra code, build, unit test, scan bảo mật.
• CD - Continuous Delivery/Deployment: Triển khai liên tục. Sau khi code đạt điều kiện, hệ thống tự động hoặc bán tự động deploy lên môi trường.

2. Mục tiêu của CI/CD

CI/CD giúp:

• Giảm thao tác thủ công khi build và deploy.
• Phát hiện lỗi sớm.
• Rút ngắn thời gian release.
• Chuẩn hóa quy trình triển khai.
• Dễ rollback khi có lỗi.
• Tăng tính ổn định của hệ thống.
• Giúp Dev, Tester, DevOps phối hợp tốt hơn.

3. Quy trình CI/CD tổng quát

Một quy trình CI/CD cơ bản thường gồm các bước:

Developer Push Code

|

v

Git Repository

|

v

CI Pipeline

|

|-- Checkout source code

|-- Install dependencies

|-- Lint / Code style check

|-- Unit test

|-- Build application

|-- Build Docker image

|-- Scan image / security scan

|-- Push image to Registry

|

v

CD Pipeline

|

|-- Deploy to Dev/Test

|-- Run smoke test

|-- Deploy to UAT

|-- Approval manual

|-- Deploy to Production

|-- Health check

|-- Monitoring

4. Các thành phần chính trong hệ thống CI/CD

4.1 Git Repository

Nơi lưu trữ source code.

Ví dụ:

Repository thường chứa:

• GitLab
• GitHub
• Bitbucket
• Azure Repos
• Source code
• Dockerfile
• File cấu hình CI/CD
• Helm chart hoặc manifest Kubernetes
• Script deploy
• File config theo môi trường

4.2 CI/CD Tool

Công cụ chạy pipeline tự động.

Ví dụ:

• GitLab CI/CD
• Jenkins
• GitHub Actions
• Argo CD
• Tekton
• Azure DevOps
• CircleCI

4.3 Runner / Agent

Runner là máy thực thi các job trong pipeline.

Ví dụ GitLab Runner có thể chạy bằng:

Runner sẽ nhận job từ GitLab CI và thực hiện các bước như build, test, push image, deploy.

• Shell executor
• Docker executor
• Kubernetes executor

4.4 Artifact

Artifact là file sinh ra sau quá trình build.

Ví dụ:

Artifact có thể được lưu lại để dùng cho bước deploy.

• File .jar
• File .war
• File binary
• File .zip
• Report test
• File build frontend

4.5 Docker Image

Với hệ thống hiện đại, app thường được đóng gói thành Docker image.

Quy trình thường là:

Build app -> Build Docker image -> Push image lên Registry -> Deploy image vào Kubernetes

4.6 Container Registry

Nơi lưu Docker image.

Ví dụ:

• Docker Hub
• GitLab Container Registry
• Harbor
• Nexus Registry
• AWS ECR
• Google Artifact Registry
• Azure Container Registry

4.7 Kubernetes / Server Deploy

Môi trường chạy ứng dụng.

Có thể deploy lên:

• VM truyền thống
• Docker Compose
• Kubernetes
• OpenShift
• ECS
• Bare metal server

5. Phân biệt CI, CD Delivery và CD Deployment

5.1 Continuous Integration

Tự động kiểm tra code sau mỗi lần push.

Ví dụ:

• Pull code
• Cài dependency
• Build
• Unit test
• Check coding convention
• Scan code

5.2 Continuous Delivery

Code sau khi build/test thành công sẽ sẵn sàng để deploy, nhưng bước deploy production cần người duyệt.

Ví dụ:

Push code -> Build -> Test -> Deploy UAT -> Manual approval -> Deploy Production

5.3 Continuous Deployment

Code sau khi pass toàn bộ kiểm tra sẽ tự động deploy lên production, không cần người duyệt.

Ví dụ:

Push code -> Build -> Test -> Deploy Production tự động

Production thường ít dùng full auto nếu hệ thống quan trọng như ngân hàng, tài chính, chính phủ.

6. Branching Strategy trong CI/CD

6.1 Git Flow

Có các nhánh:

Luồng cơ bản:

feature -> develop -> release -> main/master

• main hoặc master: production
• develop: môi trường dev
• feature/*: nhánh tính năng
• release/*: nhánh chuẩn bị release
• hotfix/*: nhánh sửa lỗi production

6.2 Trunk-based Development

Developer làm việc trên nhánh ngắn hạn, merge nhanh vào main.

Phù hợp với team có automation test tốt.

6.3 Branch theo môi trường

Một số dự án dùng:

Ví dụ:

dev -> test -> uat -> main

• dev
• test
• uat
• main hoặc master

7. Các stage phổ biến trong pipeline

7.1 Checkout

Lấy source code từ Git repository.

7.2 Install Dependencies

Cài thư viện cần thiết.

Ví dụ Node.js:

npm install

Ví dụ Java Maven:

mvn clean install

Ví dụ .NET:

dotnet restore

7.3 Lint

Kiểm tra format code, coding convention.

Ví dụ:

npm run lint

7.4 Unit Test

Chạy test ở mức function/class/module.

Ví dụ:

npm test

mvn test

dotnet test

go test ./...

7.5 Build

Build application.

Ví dụ:

npm run build

mvn clean package

dotnet publish

go build

7.6 Build Docker Image

Ví dụ:

docker build -t registry.example.com/project/app:1.0.0 .

7.7 Push Docker Image

Ví dụ:

docker push registry.example.com/project/app:1.0.0

7.8 Security Scan

Một số công cụ scan:

Ví dụ scan image bằng Trivy:

trivy image registry.example.com/project/app:1.0.0

• Trivy
• SonarQube
• Snyk
• Grype
• GitLab SAST
• OWASP Dependency Check

7.9 Deploy

Deploy lên môi trường.

Có thể dùng:

Ví dụ Kubernetes:

kubectl set image deployment/app app=registry.example.com/project/app:1.0.0 -n dev

kubectl rollout status deployment/app -n dev

• kubectl apply
• helm upgrade --install
• ansible-playbook
• docker compose up -d
• Argo CD sync

7.10 Health Check

Sau deploy cần kiểm tra app có chạy ổn không.

Ví dụ:

kubectl get pod -n dev

kubectl rollout status deployment/app -n dev

curl http://app.example.com/health

8. Ví dụ GitLab CI/CD cơ bản

File .gitlab-ci.yml:

stages:

variables:

IMAGE_NAME: "$CI_REGISTRY_IMAGE"

IMAGE_TAG: "$CI_COMMIT_SHORT_SHA"

test:

stage: test

image: node:20

script:

only:

build:

stage: build

image: node:20

script:

artifacts:

paths:

expire_in: 1 day

only:

docker-build:

stage: docker

image: docker:stable

services:

script:

only:

deploy-dev:

stage: deploy

image: bitnami/kubectl:latest

script:

only:

deploy-prod:

stage: deploy

image: bitnami/kubectl:latest

script:

only:

when: manual

• test
• build
• docker
• deploy
• npm install
• npm run lint
• npm test
• merge_requests
• dev
• main
• npm install
• npm run build
• dist/
• dev
• main
• docker:dind
• docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
• docker build -t "$IMAGE_NAME:$IMAGE_TAG" .
• docker push "$IMAGE_NAME:$IMAGE_TAG"
• dev
• main
• kubectl set image deployment/my-app my-app="$IMAGE_NAME:$IMAGE_TAG" -n dev
• kubectl rollout status deployment/my-app -n dev
• dev
• kubectl set image deployment/my-app my-app="$IMAGE_NAME:$IMAGE_TAG" -n production
• kubectl rollout status deployment/my-app -n production
• main

9. Ví dụ Jenkins Pipeline

File Jenkinsfile:

pipeline {

agent any

environment {

IMAGE_NAME = "registry.example.com/project/my-app"

IMAGE_TAG = "${env.BUILD_NUMBER}"

}

stages {

stage('Checkout') {

steps {

checkout scm

}

}

stage('Test') {

steps {

sh 'npm install'

sh 'npm test'

}

}

stage('Build') {

steps {

sh 'npm run build'

}

}

stage('Build Docker Image') {

steps {

sh 'docker build -t $IMAGE_NAME:$IMAGE_TAG .'

}

}

stage('Push Docker Image') {

steps {

sh 'docker push $IMAGE_NAME:$IMAGE_TAG'

}

}

stage('Deploy') {

steps {

sh 'kubectl set image deployment/my-app my-app=$IMAGE_NAME:$IMAGE_TAG -n dev'

sh 'kubectl rollout status deployment/my-app -n dev'

}

}

}

}

10. Deploy lên Kubernetes trong CI/CD

10.1 Dùng kubectl

Cách đơn giản:

kubectl apply -f k8s/

Hoặc update image:

kubectl set image deployment/my-app my-app=registry.example.com/my-app:tag -n dev

Kiểm tra rollout:

kubectl rollout status deployment/my-app -n dev

Rollback:

kubectl rollout undo deployment/my-app -n dev

10.2 Dùng Helm

Cài mới hoặc update app:

helm upgrade --install my-app ./helm-chart -n dev --set image.repository=registry.example.com/my-app --set image.tag=1.0.0

Rollback Helm:

helm rollback my-app 1 -n dev

10.3 Dùng Argo CD

Với GitOps, CI chỉ build image và update manifest trong Git. Argo CD sẽ tự đồng bộ manifest đó vào Kubernetes.

Luồng:

Developer push code

|

v

CI build image

|

v

Push image to registry

|

v

Update image tag trong Git manifest

|

v

Argo CD sync vào Kubernetes

11. Quản lý biến môi trường và secrets

Không nên hard-code thông tin nhạy cảm trong source code hoặc file pipeline.

Thông tin nhạy cảm gồm:

Nên lưu trong:

Ví dụ biến trong GitLab:

script:

• Password database
• Token Git
• API key
• SSH private key
• kubeconfig
• Registry password
• GitLab CI/CD Variables
• Jenkins Credentials
• GitHub Actions Secrets
• Kubernetes Secret
• Vault
• AWS Secrets Manager
• Azure Key Vault
• GCP Secret Manager
• docker login -u "$REGISTRY_USER" -p "$REGISTRY_PASSWORD" registry.example.com

12. CI/CD cho nhiều môi trường

Một hệ thống thường có các môi trường:

Luồng phổ biến:

dev branch -> deploy Dev

release branch -> deploy UAT

main/master branch -> deploy Production

Production thường cần:

• Dev: developer test nhanh.
• Test/SIT: tester kiểm thử chức năng.
• UAT: khách hàng hoặc BA nghiệm thu.
• Staging: gần giống production.
• Production: môi trường thật.
• Manual approval
• Backup trước deploy
• Health check sau deploy
• Rollback plan
• Monitoring kỹ

13. Chiến lược triển khai

13.1 Rolling Update

Update từng pod một, không dừng toàn bộ hệ thống.

Ưu điểm:

Nhược điểm:

• Đơn giản.
• Kubernetes hỗ trợ mặc định.
• Ít downtime.
• Trong lúc deploy có thể tồn tại song song version cũ và mới.

13.2 Blue-Green Deployment

Có 2 môi trường:

Sau khi test Green ổn, chuyển traffic từ Blue sang Green.

Ưu điểm:

Nhược điểm:

• Blue: version đang chạy.
• Green: version mới.
• Rollback nhanh.
• Ít rủi ro.
• Tốn tài nguyên gấp đôi.

13.3 Canary Deployment

Deploy version mới cho một phần nhỏ user trước.

Ví dụ:

95% traffic -> version cũ

5% traffic -> version mới

Nếu ổn thì tăng dần traffic.

Ưu điểm:

Nhược điểm:

• Giảm rủi ro production.
• Phù hợp hệ thống lớn.
• Cấu hình phức tạp hơn.
• Cần monitoring tốt.

14. Rollback trong CI/CD

Rollback là quay lại version cũ khi deploy lỗi.

Các cách rollback:

14.1 Rollback Kubernetes Deployment

kubectl rollout undo deployment/my-app -n production

Xem lịch sử rollout:

kubectl rollout history deployment/my-app -n production

14.2 Rollback Helm

helm history my-app -n production

helm rollback my-app 2 -n production

14.3 Rollback Docker Image Tag

Deploy lại image tag cũ:

kubectl set image deployment/my-app my-app=registry.example.com/my-app:old-tag -n production

15. Những lỗi CI/CD hay gặp

15.1 Pipeline fail do thiếu biến môi trường

Nguyên nhân:

Cách xử lý:

• Chưa khai báo variable.
• Sai tên variable.
• Variable bị protected, branch không được phép dùng.
• Kiểm tra CI/CD Variables.
• Kiểm tra protected branch/tag.
• Echo biến không nhạy cảm để debug.

15.2 Không push được image

Nguyên nhân:

Cách xử lý:

docker login registry.example.com

docker tag app:latest registry.example.com/project/app:tag

docker push registry.example.com/project/app:tag

• Sai username/password registry.
• Chưa docker login.
• Thiếu quyền push.
• Sai tên registry/repository.

15.3 Deploy Kubernetes bị lỗi imagePullBackOff

Nguyên nhân:

Kiểm tra:

kubectl describe pod <pod-name> -n <namespace>

kubectl get secret -n <namespace>

• Image tag không tồn tại.
• Kubernetes không login được private registry.
• Sai imagePullSecret.
• Sai registry URL.

15.4 Pod rollout không thành công

Nguyên nhân:

Kiểm tra:

kubectl get pod -n <namespace>

kubectl describe pod <pod-name> -n <namespace>

kubectl logs <pod-name> -n <namespace>

• App crash.
• ConfigMap/Secret sai.
• Liveness/readiness probe fail.
• Không kết nối được database/message queue.

16. Best practices CI/CD

Nên áp dụng:

• Pipeline càng đơn giản càng tốt.
• Không hard-code password/token.
• Dùng image tag rõ ràng, không nên chỉ dùng latest.
• Có stage test trước khi deploy.
• Production nên có manual approval.
• Có rollback plan.
• Có health check sau deploy.
• Có log và monitoring.
• Tách config theo môi trường.
• Build một lần, deploy nhiều môi trường.
• Không build lại image khác nhau cho từng môi trường nếu cùng version.
• Dùng artifact hoặc image immutable.
• Scan bảo mật source code và image.
• Giới hạn quyền của CI/CD token.
• Runner nên tách biệt theo môi trường quan trọng.

17. Quy trình CI/CD thực tế cho doanh nghiệp

Ví dụ quy trình chuẩn:

1. Developer tạo feature branch.

2. Developer push code lên Git.

3. Pipeline chạy lint, test, build.

4. Developer tạo merge request.

5. Reviewer review code.

6. Merge vào dev.

7. CI build Docker image và push registry.

8. CD deploy tự động lên Dev.

9. Tester kiểm thử trên Dev/Test.

10. Merge sang release hoặc uat.

11. Deploy lên UAT.

12. Khách hàng hoặc BA nghiệm thu.

13. Merge sang main/master.

14. Pipeline production chạy.

15. DevOps hoặc Lead duyệt manual approval.

16. Deploy production.

17. Health check.

18. Monitoring log/metrics.

19. Rollback nếu có lỗi.

18. Câu hỏi phỏng vấn CI/CD thường gặp

18.1 CI/CD là gì?

CI/CD là quy trình tự động hóa từ lúc developer push code đến khi build, test, đóng gói và deploy ứng dụng lên môi trường. CI tập trung vào tích hợp và kiểm tra code liên tục. CD tập trung vào triển khai ứng dụng một cách tự động hoặc bán tự động.

18.2 Pipeline gồm những bước nào?

Một pipeline thường gồm:

checkout -> install dependencies -> lint -> test -> build -> docker build -> scan -> push image -> deploy -> health check

18.3 Artifact khác Docker image như nào?

Artifact là sản phẩm sau build, ví dụ file .jar, .war, dist/. Docker image là gói chạy hoàn chỉnh gồm app, runtime, dependency và cấu hình cần thiết để chạy trong container.

18.4 Làm sao rollback khi deploy lỗi?

Nếu dùng Kubernetes:

kubectl rollout undo deployment/<deployment-name> -n <namespace>

Nếu dùng Helm:

helm rollback <release-name> <revision> -n <namespace>

Nếu dùng Docker image tag thì deploy lại tag cũ.

18.5 Tại sao không nên dùng tag latest?

Vì latest không rõ version thật đang chạy, khó rollback, khó audit và dễ deploy nhầm. Nên dùng tag theo commit SHA, version hoặc build number.

Ví dụ:

app:1.0.0

app:20260702-1200

app:8f3a9c1

18.6 CI/CD liên quan gì đến DevOps?

CI/CD là một phần quan trọng của DevOps. DevOps không chỉ là tool, mà là cách phối hợp giữa Dev, Ops, QA để release phần mềm nhanh hơn, ổn định hơn và ít lỗi hơn.

19. Checklist CI/CD trước khi lên Production

Trước khi deploy production cần kiểm tra:

• Code đã được review.
• Pipeline test pass.
• Image đã được build thành công.
• Image đã được scan bảo mật.
• Config production đúng.
• Secret production đúng.
• Database migration đã được kiểm tra.
• Có backup nếu cần.
• Có rollback plan.
• Có người trực monitoring sau deploy.
• Có health check endpoint.
• Có log/metrics/alert.
• Có manual approval.
• Có thông báo release cho team liên quan.

20. Tóm tắt ngắn gọn

CI/CD là quy trình tự động hóa build, test và deploy phần mềm.

Một pipeline tốt cần có:

Code -> Test -> Build -> Package -> Scan -> Deploy -> Verify -> Monitor

Với DevOps, cần hiểu rõ:

CI/CD không chỉ là viết file pipeline, mà là thiết kế quy trình release an toàn, nhanh và có khả năng khôi phục khi xảy ra lỗi.

• Git flow.
• Pipeline stages.
• Docker image.
• Registry.
• Kubernetes deploy.
• Helm hoặc kubectl.
• Secret management.
• Rollback.
• Monitoring sau deploy.
• Bảo mật trong pipeline.

Bước tiếp theo

Nếu áp dụng vào dự án thật, hãy bắt đầu bằng phiên bản nhỏ nhất có thể đo được, ghi lại quyết định kỹ thuật, rồi cải tiến dựa trên log và phản hồi người dùng.