CI/CD là gì?
CI/CD là viết tắt của Continuous Integration (Tích hợp liên tục) và Continuous Delivery/Deployment (Triển khai liên tục). Nói đơn giản, đây là một quy trình giúp việc phát triển phần mềm trở nên nhanh chóng, ổn định và ít lỗi hơn.
Ở bước CI (Tích hợp liên tục), mỗi khi lập trình viên đẩy code mới lên Git, hệ thống sẽ tự động kiểm tra xem code đó có bị lỗi không (ví dụ: chạy unit test, kiểm tra style code, build thử...). Nhờ đó, mình có thể phát hiện lỗi sớm và sửa ngay khi còn dễ.
Sau khi code đã ổn, đến phần CD. Tùy vào cách tổ chức, CD có thể là:
Continuous Delivery: code được đóng gói và sẵn sàng triển khai, nhưng vẫn cần người bấm nút để đẩy lên môi trường thật.
Continuous Deployment: code tự động được triển khai lên môi trường thật luôn, không cần thao tác tay.
Nhờ CI/CD, mình tiết kiệm rất nhiều thời gian trong việc kiểm tra và triển khai phần mềm, đồng thời giảm rủi ro do lỗi người gây ra khi làm thủ công.
Trong bài viết này mình sẽ chia sẻ đến các bạn một luồng CI/CD "hoàn thiện" trong thực tế trông sẽ thế nào, dựa trên kinh nghiệm làm việc của mình như một DevOps Engineer.
1. Continuous Integration (Tích hợp liên tục)
1.1 Code Checkout / Clone
Trước khi bắt đầu bất cứ quá trình CI/CD nào ta cũng cần pull/clone về source code tại các nơi lưu trữ code như Github, Gitlab để có thể thực hiện build source code ra phiên bản hoàn thiện hoặc chạy kiểm thử trên source code.
| Loại | Công cụ thường dùng |
|---|---|
| Source Control | GitHub, GitLab, Bitbucket, Azure Repos, Gitea,... |
1.2 Build/Install dependencies
Việc cài đặt phụ thuộc sẽ tải về và cài đặt các thư viện bên thứ 3 ,thư viện phụ thuộc hoặc gói cài đặt liên quan mà không thể xem trực tiếp được trong source code nếu không chạy cài đặt.
Bước này là cần thiết để có thể chạy được các bước phân tích tiếp theo hiệu quả. Tùy thuộc vào kiểu ứng dụng của bạn có chạy dưới dạng container hay không và loại ngôn ngữ mà bạn có thể chọn được công cụ phù hợp
| Loại | Công cụ thường dùng |
|---|---|
| Công cụ build cho từng ngôn ngữ | Maven, Gradle, sbt, npm/yarn/pnpm, pip/Poetry, Cargo, Go modules, Bazel, Buck, CMake, Make, MSBuild, dotnet CLI |
| Container & image build | Docker CLI/BuildKit, Buildah, Kaniko, Podman, Jib, ko, img, buildpacks (Paketo, Cloud Native Buildpacks) |
1.3 Static Code Analysis
Khi một nhóm phát triển phần mềm làm việc cùng nhau, sẽ có rất nhiều đoạn mã được viết ra mỗi ngày. Dù mọi người đều cố gắng viết code tốt, nhưng con người vẫn dễ mắc lỗi, nhất là những lỗi nhỏ khó nhìn thấy ngay.
Static Code Analysis là cách mà mình dùng công cụ để tự động kiểm tra mã nguồn mà không cần chạy ứng dụng. Nó giống như việc bạn soát lỗi chính tả trong văn bản trước khi gửi email – nhưng ở đây là soát lỗi trong code.
Đầu vào của bước này sẽ là 2 bước trên
Source codevàcontainer image
Các bước phân tích này có thể chạy đồng thời để tiết kiệm thời gian.
| Loại phân tích | Công cụ thường dùng | Mục đích |
|---|---|---|
| Lint / style check | ESLint, Pylint, Flake8, RuboCop, Prettier, Stylelint, go vet, golangci-lint |
Kiểm tra lỗi cú pháp, chuẩn hóa code theo quy định, giúp code dễ đọc và dễ bảo trì hơn |
| Unit testing & coverage | JUnit, TestNG, pytest, unittest, jest, mocha, RSpec, go test, NUnit, xUnit |
Đảm bảo các hàm, module hoạt động đúng như mong muốn và đo mức độ bao phủ của test |
| Code coverage reporting | JaCoCo, Istanbul/nyc, Coverlet, Codecov, SonarCloud, Clover | Hiển thị trực quan phần nào của mã nguồn đã được kiểm thử, từ đó cải thiện chất lượng test |
| Static application security testing (SAST) | SonarQube, Semgrep, Checkmarx, Veracode, GitHub CodeQL, Fortify, Coverity | Quét mã nguồn để phát hiện lỗ hổng bảo mật tiềm ẩn trước khi ứng dụng được build hoặc chạy |
| Secrets detection | TruffleHog, Gitleaks, Detect-Secrets, GitGuardian | Phát hiện các thông tin nhạy cảm (API keys, mật khẩu...) bị lộ trong mã nguồn |
| License & SCA (open-source risk) | Snyk, Black Duck, WhiteSource, Mend (trước đây là WhiteSource), FOSSA, OWASP Dependency-Check | Kiểm tra các thư viện mã nguồn mở có sử dụng license hợp lệ và không chứa lỗ hổng bảo mật |
| Container scanning | Trivy, Grype, Clair, Anchore, Snyk, Docker Scout, Aqua, Prisma Cloud | Phân tích image container để phát hiện lỗ hổng bảo mật, thư viện lỗi thời, hoặc cấu hình không an toàn |
1.4 Build Artifact Packaging & Signing
Sau khi bước trên đã qua với kết quả tốt và không có lỗi gì nghiêm trọng ta sẽ đến với bước tiếp theo. Đóng gói lại ứng dụng và đẩy lên kho chứa.
Các bước sau cần được chạy tuần tự
| Bước | Mục đích | Công cụ thường dùng | Giải thích dễ hiểu |
|---|---|---|---|
| 1. Package binaries | Đóng gói mã nguồn đã build thành định dạng chuẩn để sử dụng hoặc triển khai | JAR, WAR, NuGet, PyPI wheels, OCI images, Helm charts, Debian/RPM, container SBOM |
Sau khi build xong, code được đóng gói lại thành các file mà hệ thống hoặc người dùng có thể sử dụng được. Tùy vào ngôn ngữ hoặc môi trường, định dạng có thể là JAR (Java), PyPI (Python), Docker image, Helm chart (K8s), v.v. Container SBOM là danh sách các thành phần có trong image để kiểm tra bảo mật. |
| 2. Artifact/Image signing & provenance (optional) | Ký số và xác minh nguồn gốc (ai tạo ra, có bị thay đổi gì không) để đảm bảo tính tin cậy và an toàn của gói phần mềm | cosign, Notary v2, JReleaser, GPG, AWS KMS, HashiCorp Vault |
Giống như bạn ký tên hoặc đóng dấu vào một gói hàng, ký số giúp xác nhận đây là artifact "chính chủ", không bị giả mạo. Nếu sau này có sự cố, bạn có thể biết chính xác ai build ra nó, và liệu nó có bị can thiệp hay không. |
| 3. Push artifacts | Đưa artifact/image đã đóng gói và ký số lên kho lưu trữ để các môi trường khác (dev, staging, prod) có thể truy cập và triển khai | JFrog Artifactory, Sonatype Nexus, GitHub Packages, GitLab Package Registry, Azure Artifacts, S3/GCS buckets, Docker Hub, ECR, GCR, OCI-compatible registries |
Artifact được upload lên các "kho chứa" (registry hoặc artifact store) để người khác (hoặc hệ thống CI/CD) có thể lấy về sử dụng. Ví dụ: upload Docker image lên Docker Hub, Helm chart lên GCS bucket, hoặc .jar lên GitHub Packages. Đây là bước kết nối giữa quá trình build và môi trường triển khai thực tế. |
Như vậy khi đến đây là cơ bản chúng ta đã hoàn thành bước CI - Continuous Integration
2. Continuous Delivery / Deployment (Triển khai liên tục)
2.1 Fetch Build Artifact
Bắt đầu với bước CD ta cần tải về hoặc lấy thống tin Build Artifact đã xây dựng từ bước cuối cùng của quá trình CI.
Việc tải về Image, file thực thi giúp ta có thể triển khai ứng dụng lên các môi trường khác nhau trong các bước tiếp theo
2.2 Deploy non-production environment
Trong thực tế ta sẽ luôn có các môi trường kiểm thử như: Dev, Staging, UAT, Preprod để các bên liên quan có thể vào kiểm tra xem ứng dụng có hoạt động như kỳ vọng hay không
Từ phía là DevOps Engineer, ta có thể tích hợp các công cụ để tự động kiểm thử ở trên môi trường này.
Tùy thuộc vào từng chiến lược triển khai khác nhau mà bạn muốn sử dụng chúng ta sẽ có những lựa chọn về công cụ khác nhau.
| Chiến lược triển khai | Công cụ |
|---|---|
| Helm package & release | Helm, Helmfile, Reckoner |
| Progressive delivery (GitOps) | Argo CD, Flux CD, Jenkins X, Google Config Sync, Spinnaker, Harness CD |
| Blue/Green & canary | Flagger, Argo Rollouts, Spinnaker, Istio, Linkerd, AWS CodeDeploy |
| Serverless deploy | Serverless Framework, AWS SAM, Terraform, Pulumi, SST |
| Mobile / desktop release | Fastlane, Microsoft App Center, Google Play Console pipelines |
| Feature flag rollout | LaunchDarkly, Flagsmith, Unleash, Split, CloudBees Rollout |
2.3 Run tests/scans on non-production environments
Việc chạy kiểm thử trên môi trường non-production có thể chạy trên nhiều lần trên nhiều môi trường.
Tùy thuộc vào các loại ứng dụng mà chúng ta cần chọn các loại kiểm thử phù hợp, không nhất thiết phải chạy toàn bộ các loại kiểm thử này.
| Loại kiểm thử | Công cụ thường dùng | Mục đích |
|---|---|---|
| Browser / UI Testing | Selenium WebDriver, Cypress, Playwright, TestCafe, Puppeteer | Mô phỏng người dùng thao tác trên trình duyệt để kiểm tra giao diện và luồng hoạt động của ứng dụng web |
| Mobile App Testing | Appium, Detox, Espresso | Kiểm thử chức năng và giao diện của ứng dụng mobile (Android/iOS) như người dùng thật |
| Load & Performance Testing | JMeter, Gatling, Locust, K6, Artillery, Vegeta | Đo lường hiệu suất ứng dụng khi có nhiều người dùng truy cập cùng lúc, tìm điểm nghẽn, đo thời gian phản hồi |
| Chaos / Resiliency Testing | Gremlin, ChaosMesh, LitmusChaos, PowerfulSeal | Kiểm tra khả năng chịu lỗi của hệ thống bằng cách tạo lỗi giả lập (mất mạng, chết service...) |
| Black-box DAST (Security) | OWASP ZAP, Burp Suite Pro, Arachni, Netsparker, Tenable Web App Scan | Quét bảo mật ứng dụng đang chạy (giống như hacker bên ngoài tấn công), tìm lỗ hổng như XSS, SQLi... |
| Fuzz Testing (Security) | Jazzer, go-fuzz, libFuzzer, AFL++, Defensics | Gửi dữ liệu ngẫu nhiên vào ứng dụng để tìm crash hoặc lỗi bảo mật chưa biết trước (zero-day) |
| Container Image Scanning | Trivy, Grype, Anchore Engine, Clair, Aqua Microscanner | Kiểm tra Docker image để phát hiện thư viện chứa lỗ hổng bảo mật hoặc cấu hình không an toàn |
2.4 Deploy production environment
Sau khi kiểm thử và chạy các quét bảo mật trực tiếp trên môi trường non-production không có vấn đề gì, ta có thể thực hiện quá trình tiếp theo và triển khai lên môi trường production cho người dùng thật.
Các công cụ để deploy trong môi trường production cũng sẽ tương tự khi triển khai môi trường non-production
Bước triển khai lên môi trường production nên được duyệt thủ công để tránh xảy ra sự cố
2.5 Post‑Deployment Validation
Sau khi deploy môi trường production không phải là đã kết thúc CI/CD pipeline. Lại một lần nữa sau khi hoàn tất deploy production mà không có vấn đề gì ta cần chạy lại hoặc thêm 1 số loại test nữa để đảm bảo không có lỗi gì không xuất hiện trên non-production env mà xuất hiện trên production.
| Loại kiểm thử | Công cụ |
|---|---|
| Smoke / sanity tests in target env | Bats‑core, newman, curl + bash scripts, canary synthetic checks |
| Contract & health checks | Spring Boot Actuator, Kubernetes readiness/liveness probes |
2.6 Rollback & Disaster Recovery
Đây là một bước mà rất nhiều người sẽ bỏ quên. Bước này giúp bạn rollback ứng dụng lại phiên bản ngay trước đó khi phiên bản mới gặp lỗi. Công cụ được sử dụng để rollback thường sẽ chính là công cụ bạn sử dụng để triển khai ứng dụng.
| Nhiệm vụ | Công cụ thường dùng |
|---|---|
| Tự động rollback khi có sự cố | Argo Rollouts, Spinnaker, Harness, Kubernetes Deployments with health‑checks |
| Disaster Recovery | Velero, AWS Backup, Azure Backup, Google Cloud Backup & DR |
2.7 Notify & Document Release
Tại bước cuối cùng này ta cần gửi thông báo về trạng thái phiên bản mới đã được triển khai cùng với thông tin thay đổi cho các bên liên quan, ở đây có thể là development team, khách hàng, PM,...
| Mục đích | Công cụ |
|---|---|
| Auto‑generated docs | mkdocs‑material, Docusaurus, Sphinx, Swagger/OpenAPI, Storybook |
| Release notes & changelog | Release Drafter, auto‑changelog, GitHub Releases, Keep a Changelog |
| ChatOps notifications | Slack Apps/Bot, Microsoft Teams, Mattermost, Discord webhooks |
Infrastructure pipeline (Bonus)
Ngoài việc pipeline để triển khai ứng dụng chúng ta còn có các pipeline để triển khai hạ tầng giúp chạy ứng dụng. Sau đây là một vài công cụ có thể tham khảo cho pipeline provision hạ tầng này:
Infrastructure‑as‑Code (IaC) & Policy Scan
| Format | Validators / linters |
|---|---|
| Terraform | terraform validate, TFLint, tfsec, Checkov, Terrascan, Infracost, Regula |
| Kubernetes manifests | kube‑score, kube‑lint, Kubeval, Kube‑No‑Trouble, Polaris, OPA Conftest |
| Helm charts | helm lint, chart‑testing, Datree |
| Cloud formation | cfn‑lint, CFN‑Guard |
| Packer | packer validate, Packer Inspector |
Environment Provisioning & Configuration
| Automation layer | Popular tools |
|---|---|
| Provision infra | Terraform, Pulumi, Crossplane, AWS CloudFormation, Azure Bicep, Google Cloud Config Connector |
| Configuration management | Ansible, Chef, Puppet, SaltStack |
| Container platform bootstrapping | Kubernetes (kops, kube‑adm), EKS‑Blueprints, Rancher, OpenShift, K3s, Kind for testing |
| Secrets & parameter store | HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Sealed Secrets, Doppler |
Kết
Như vậy mình đã đi qua những bước chính có trong một pipeline CI/CD thông dụng hiện tại và các công cụ bạn có thể sử dụng trong từng bước đó. Hy vọng bài viết đã giúp bạn có một cái nhìn tổng quan về các bước cần có trong CI/CD.
Nếu bài viết có ích cho bạn hãy Follow và Upvote bài viết để ủng hộ mình nhé. Cám ơn bạn 
Nếu như bạn đang gặp khó khăn trong vấn đề chuyên môn, cần người hỗ trợ về mặt hệ thống, DevOps tools hay cần định hướng trong công việc thì mình tự tin có thể hỗ trợ được bạn. Liên hệ với mình để trao đổi thêm nhé https://hoangviet.io.vn/, mình rất vui khi được trao đổi và cộng tác với bạn.