Tweet
CI/CD (Phần 2): Chỉ một lỗi nhỏ cũng đủ để chặn cả Pipeline – và đó là điều chúng ta mong muốn
Một developer vừa commit code lên Git. Chỉ vài giây sau, CI/CD Pipeline được kích hoạt. Hệ thống bắt đầu build, chạy static analysis, unit test, kiểm tra dependencies...
Mọi thứ diễn ra hoàn toàn tự động.
Đột nhiên một job báo lỗi.
Ngay lập tức toàn bộ pipeline dừng lại.
Nghe có vẻ "khó chịu", nhưng đây chính là cơ chế giúp hàng nghìn công ty công nghệ triển khai phần mềm nhiều lần mỗi ngày mà vẫn đảm bảo chất lượng.
Điều gì xảy ra sau mỗi lần Commit?
Trong một hệ thống CI/CD hiện đại, quy trình thường diễn ra như sau:
Đây chính là nguyên tắc:
Thông báo lỗi không còn chỉ là Email
Ngày nay, rất nhiều doanh nghiệp không còn phụ thuộc vào Email.
Pipeline có thể gửi thông báo trực tiếp lên:
Toàn bộ nhóm phát triển đều nhìn thấy:
Nhờ đó việc xử lý sự cố diễn ra nhanh hơn rất nhiều.
Những nguyên nhân khiến Pipeline thất bại nhiều nhất
1. Lỗi cấu hình Pipeline
Đây là lỗi rất phổ biến.
Đa số các hệ thống hiện nay sử dụng file YAML để định nghĩa Pipeline như:
YAML rất dễ đọc nhưng cực kỳ "khó tính".
Chỉ cần:
là Pipeline sẽ dừng ngay lập tức. Jenkins là một ngoại lệ khi sử dụng Groovy DSL thay vì YAML để định nghĩa Pipeline.
2. Thiếu Dependency
Một developer nâng phiên bản thư viện.
Máy của họ vẫn chạy bình thường.
Nhưng CI Server không có đúng phiên bản đó.
Kết quả:
ModuleNotFoundError
ImportError
Dependency not found
Pipeline dừng.
Đây là lý do các dự án luôn quản lý dependency rất chặt bằng:
3. Static Code Analysis thất bại
Các công cụ như:
có thể phát hiện:
Tất cả đều được kiểm tra trước khi ứng dụng được build.
4. Unit Test thất bại
Nếu dự án áp dụng Test-Driven Development (TDD) thì mỗi chức năng đều có Unit Test.
Chỉ cần một Unit Test fail...
Pipeline dừng.
Không có ngoại lệ.
Đây chính là "hàng rào" ngăn bug đi xa hơn trong quy trình phát triển.
5. Deployment thất bại
Ngay cả khi build thành công và test đều đạt, việc triển khai lên môi trường Staging vẫn có thể gặp lỗi:
Trong trường hợp đó, Pipeline cũng sẽ dừng để tránh đưa một phiên bản chưa sẵn sàng lên Production.
Vì sao doanh nghiệp đầu tư rất nhiều cho Automated Testing?
Khi số lượng test tăng lên hàng trăm hoặc hàng nghìn, việc kiểm thử thủ công gần như không còn khả thi.
Automated Testing mang lại nhiều lợi ích quan trọng:
Một Pipeline tốt không chỉ giúp tự động hóa việc build hay deploy.
Quan trọng hơn, nó trở thành "người gác cổng" của toàn bộ quy trình DevSecOps, đảm bảo chỉ những phiên bản đã vượt qua tất cả các bài kiểm tra mới được phép tiến gần hơn đến môi trường Production.
Ở bài tiếp theo, chúng ta sẽ đi sâu vào Dynamic Testing, Code Coverage, OWASP Top 10 Testing và cách các doanh nghiệp kết hợp Static Analysis với Dynamic Analysis để xây dựng một CI/CD Pipeline đạt chuẩn DevSecOps hiện đại.
Một developer vừa commit code lên Git. Chỉ vài giây sau, CI/CD Pipeline được kích hoạt. Hệ thống bắt đầu build, chạy static analysis, unit test, kiểm tra dependencies...
Mọi thứ diễn ra hoàn toàn tự động.
Đột nhiên một job báo lỗi.
Ngay lập tức toàn bộ pipeline dừng lại.
Nghe có vẻ "khó chịu", nhưng đây chính là cơ chế giúp hàng nghìn công ty công nghệ triển khai phần mềm nhiều lần mỗi ngày mà vẫn đảm bảo chất lượng.
Điều gì xảy ra sau mỗi lần Commit?
Trong một hệ thống CI/CD hiện đại, quy trình thường diễn ra như sau:
- Developer commit code lên repository.
- Webhook của GitHub, GitLab hoặc Bitbucket gửi thông báo đến CI/CD Server.
- CI/CD Server tự động khởi động Pipeline.
- Pipeline thực hiện hàng loạt bước kiểm tra.
- Nếu chỉ một job thất bại, toàn bộ Pipeline sẽ dừng và gửi thông báo cho nhóm phát triển.
Đây chính là nguyên tắc:
Không cho phép mã nguồn có vấn đề đi tiếp xuống các giai đoạn phía sau.
Thông báo lỗi không còn chỉ là Email
Ngày nay, rất nhiều doanh nghiệp không còn phụ thuộc vào Email.
Pipeline có thể gửi thông báo trực tiếp lên:
- Microsoft Teams
- Slack
- Discord
- Mattermost
- Telegram
- ChatOps Bot
Toàn bộ nhóm phát triển đều nhìn thấy:
- Ai là người commit
- Commit nào gây lỗi
- Job nào thất bại
- Log chi tiết
- Pipeline đang dừng ở đâu
Nhờ đó việc xử lý sự cố diễn ra nhanh hơn rất nhiều.
Những nguyên nhân khiến Pipeline thất bại nhiều nhất
1. Lỗi cấu hình Pipeline
Đây là lỗi rất phổ biến.
Đa số các hệ thống hiện nay sử dụng file YAML để định nghĩa Pipeline như:
- .gitlab-ci.yml
- github-workflows.yml
- azure-pipelines.yml
YAML rất dễ đọc nhưng cực kỳ "khó tính".
Chỉ cần:
- sai indentation
- thừa khoảng trắng
- dùng Tab thay vì Space
là Pipeline sẽ dừng ngay lập tức. Jenkins là một ngoại lệ khi sử dụng Groovy DSL thay vì YAML để định nghĩa Pipeline.
2. Thiếu Dependency
Một developer nâng phiên bản thư viện.
Máy của họ vẫn chạy bình thường.
Nhưng CI Server không có đúng phiên bản đó.
Kết quả:
ModuleNotFoundError
ImportError
Dependency not found
Pipeline dừng.
Đây là lý do các dự án luôn quản lý dependency rất chặt bằng:
- requirements.txt
- package.json
- pom.xml
- go.mod
- Pipfile
- Poetry
3. Static Code Analysis thất bại
Các công cụ như:
- Bandit
- Pylint
- Mypy
- Vulture
- Prospector
có thể phát hiện:
- lỗi cú pháp
- coding style
- insecure coding
- dead code
- type mismatch
Tất cả đều được kiểm tra trước khi ứng dụng được build.
4. Unit Test thất bại
Nếu dự án áp dụng Test-Driven Development (TDD) thì mỗi chức năng đều có Unit Test.
Chỉ cần một Unit Test fail...
Pipeline dừng.
Không có ngoại lệ.
Đây chính là "hàng rào" ngăn bug đi xa hơn trong quy trình phát triển.
5. Deployment thất bại
Ngay cả khi build thành công và test đều đạt, việc triển khai lên môi trường Staging vẫn có thể gặp lỗi:
- thiếu biến môi trường
- cấu hình sai
- thiếu quyền truy cập
- dịch vụ chưa khởi động
- lỗi kết nối cơ sở dữ liệu
Trong trường hợp đó, Pipeline cũng sẽ dừng để tránh đưa một phiên bản chưa sẵn sàng lên Production.
Vì sao doanh nghiệp đầu tư rất nhiều cho Automated Testing?
Khi số lượng test tăng lên hàng trăm hoặc hàng nghìn, việc kiểm thử thủ công gần như không còn khả thi.
Automated Testing mang lại nhiều lợi ích quan trọng:
- Cung cấp cái nhìn tức thời về trạng thái của toàn bộ dự án.
- Xác định chính xác commit đầu tiên làm hệ thống bị lỗi.
- Đảm bảo các test có thể chạy trên mọi môi trường, không phụ thuộc vào máy của một developer.
- Hỗ trợ xử lý đồng thời khi nhiều test cùng sử dụng tài nguyên dùng chung.
- Tạo sự tự tin để nhóm phát triển refactor hoặc bổ sung tính năng mới mà không lo làm hỏng các chức năng cũ.
Một Pipeline tốt không chỉ giúp tự động hóa việc build hay deploy.
Quan trọng hơn, nó trở thành "người gác cổng" của toàn bộ quy trình DevSecOps, đảm bảo chỉ những phiên bản đã vượt qua tất cả các bài kiểm tra mới được phép tiến gần hơn đến môi trường Production.
Ở bài tiếp theo, chúng ta sẽ đi sâu vào Dynamic Testing, Code Coverage, OWASP Top 10 Testing và cách các doanh nghiệp kết hợp Static Analysis với Dynamic Analysis để xây dựng một CI/CD Pipeline đạt chuẩn DevSecOps hiện đại.
Attached Files