Tweet
Một CI/CD Pipeline có thể gồm rất nhiều giai đoạn: Build, Test, Security Scan, Deploy...
Nhưng tất cả đều có chung một điểm khởi đầu.
Đó là Build Stage.
Nếu Build thất bại, sẽ không có Unit Test nào được chạy, không có Security Scan nào được thực hiện và cũng không có ứng dụng nào được triển khai.
Đây chính là "cánh cổng đầu tiên" của mọi quy trình CI/CD hiện đại.
Build Stage là gì?
Build Stage là giai đoạn đầu tiên trong hầu hết các CI/CD Pipeline.
Nhiệm vụ của nó là biến source code trong repository thành một artifact có thể thực thi, sẵn sàng cho các bước kiểm thử và triển khai phía sau.
Tùy theo loại ứng dụng, công việc của Build Stage sẽ khác nhau.
Ví dụ:
Nói cách khác, đây là nơi mã nguồn được "đóng gói" thành sản phẩm mà các giai đoạn tiếp theo có thể sử dụng.
Điều gì kích hoạt Build Stage?
Trong phần lớn doanh nghiệp, Build Stage không được chạy thủ công.
Pipeline thường được kích hoạt khi developer push code lên repository.
Tuy nhiên, các hệ thống CI/CD hiện đại cho phép thiết lập những điều kiện linh hoạt hơn, chẳng hạn:
Nhờ đó, doanh nghiệp có thể kiểm soát chính xác thời điểm Build và Test diễn ra.
Ai chịu trách nhiệm kích hoạt Pipeline?
Nếu sử dụng các nền tảng quản lý mã nguồn tích hợp CI/CD như:
thì việc kích hoạt Pipeline đã được tích hợp sẵn.
Trong khi đó, nếu sử dụng các hệ thống CI độc lập như:
repository sẽ cần gửi Webhook hoặc một cơ chế tương tự để thông báo rằng có commit mới và Pipeline cần được khởi động.
Build Stage trong môi trường Docker
Ngày nay, phần lớn ứng dụng cloud-native đều được đóng gói dưới dạng container.
Một Build Stage điển hình sẽ thực hiện các bước sau:
Git Repository
│
▼
Clone Source Code (nếu cần)
│
▼
docker build
│
▼
Docker Image
│
▼
Push Container Registry
Nếu Pipeline chạy ngay trên nền tảng như GitLab CI, mã nguồn của đúng repository và đúng branch thường đã sẵn sàng, nên không cần bước tải mã nguồn thủ công. Sau khi docker build thành công, Docker Image sẽ được đẩy lên Container Registry để phục vụ các giai đoạn Test và Deploy.
Artifact là gì?
Không phải Pipeline nào cũng đẩy ngay Docker Image lên Registry.
Nhiều tổ chức sử dụng Artifacts.
Artifact là sản phẩm được tạo ra sau Build, có thể là:
Artifact sẽ được lưu lại và chuyển cho các Stage tiếp theo sử dụng mà không cần Build lại từ đầu. Điều này giúp bảo đảm rằng tất cả các bước kiểm thử và triển khai đều sử dụng đúng một phiên bản đã được tạo ra ở Build Stage.
Có nên chia Build thành thật nhiều Job?
Câu trả lời là không phải lúc nào cũng nên.
Về lý thuyết, việc chia nhỏ thành nhiều Job giúp quy trình rõ ràng hơn. Tuy nhiên, với nhiều hệ thống CI/CD sử dụng Docker, mỗi Job thường phải:
Nếu chia quá nhiều Job, chi phí khởi tạo container, truyền artifact và đồng bộ cache có thể trở thành một phần đáng kể trong tổng thời gian Pipeline. Vì vậy, nên cân bằng giữa khả năng bảo trì Pipeline và hiệu năng thực thi, thay vì tách nhỏ mọi tác vụ.
Build thành công chưa có nghĩa là phần mềm đã "đạt"
Hoàn thành Build chỉ chứng minh rằng mã nguồn có thể được đóng gói thành công.
Để được triển khai, ứng dụng vẫn phải vượt qua nhiều "cửa kiểm tra" khác như:
Chỉ khi tất cả các Stage đều thành công, Pipeline mới tiếp tục đến bước triển khai.
Build Stage chính là nền móng của toàn bộ CI/CD Pipeline. Một quy trình Build được thiết kế tốt sẽ tạo ra artifact nhất quán, có thể tái sử dụng và sẵn sàng cho mọi bước kiểm thử tiếp theo. Đây cũng là lý do các hệ thống DevSecOps hiện đại đầu tư rất nhiều vào việc chuẩn hóa Build, container hóa ứng dụng và quản lý artifact một cách chặt chẽ trước khi phần mềm tiến gần đến môi trường Production.
Nhưng tất cả đều có chung một điểm khởi đầu.
Đó là Build Stage.
Nếu Build thất bại, sẽ không có Unit Test nào được chạy, không có Security Scan nào được thực hiện và cũng không có ứng dụng nào được triển khai.
Đây chính là "cánh cổng đầu tiên" của mọi quy trình CI/CD hiện đại.
Build Stage là gì?
Build Stage là giai đoạn đầu tiên trong hầu hết các CI/CD Pipeline.
Nhiệm vụ của nó là biến source code trong repository thành một artifact có thể thực thi, sẵn sàng cho các bước kiểm thử và triển khai phía sau.
Tùy theo loại ứng dụng, công việc của Build Stage sẽ khác nhau.
Ví dụ:
- Với Node.js, Build Stage thường chạy npm để cài đặt các package và chuẩn bị môi trường thực thi.
- Với các ứng dụng được container hóa, Build Stage sẽ sử dụng docker build cùng Dockerfile trong repository để tạo Docker Image.
Nói cách khác, đây là nơi mã nguồn được "đóng gói" thành sản phẩm mà các giai đoạn tiếp theo có thể sử dụng.
Điều gì kích hoạt Build Stage?
Trong phần lớn doanh nghiệp, Build Stage không được chạy thủ công.
Pipeline thường được kích hoạt khi developer push code lên repository.
Tuy nhiên, các hệ thống CI/CD hiện đại cho phép thiết lập những điều kiện linh hoạt hơn, chẳng hạn:
- Push vào branch develop
- Merge Feature Branch vào develop
- Merge Request hoặc Pull Request được chấp nhận
- Tạo Release Tag
- Hoặc người dùng chủ động chạy Pipeline từ giao diện quản trị.
Nhờ đó, doanh nghiệp có thể kiểm soát chính xác thời điểm Build và Test diễn ra.
Ai chịu trách nhiệm kích hoạt Pipeline?
Nếu sử dụng các nền tảng quản lý mã nguồn tích hợp CI/CD như:
- GitHub
- GitLab
- Bitbucket
thì việc kích hoạt Pipeline đã được tích hợp sẵn.
Trong khi đó, nếu sử dụng các hệ thống CI độc lập như:
- Jenkins
- Travis CI
- Semaphore
repository sẽ cần gửi Webhook hoặc một cơ chế tương tự để thông báo rằng có commit mới và Pipeline cần được khởi động.
Build Stage trong môi trường Docker
Ngày nay, phần lớn ứng dụng cloud-native đều được đóng gói dưới dạng container.
Một Build Stage điển hình sẽ thực hiện các bước sau:
Git Repository
│
▼
Clone Source Code (nếu cần)
│
▼
docker build
│
▼
Docker Image
│
▼
Push Container Registry
Nếu Pipeline chạy ngay trên nền tảng như GitLab CI, mã nguồn của đúng repository và đúng branch thường đã sẵn sàng, nên không cần bước tải mã nguồn thủ công. Sau khi docker build thành công, Docker Image sẽ được đẩy lên Container Registry để phục vụ các giai đoạn Test và Deploy.
Artifact là gì?
Không phải Pipeline nào cũng đẩy ngay Docker Image lên Registry.
Nhiều tổ chức sử dụng Artifacts.
Artifact là sản phẩm được tạo ra sau Build, có thể là:
- File thực thi
- Binary
- Package
- Docker Image
- File cấu hình
- Báo cáo Build
Artifact sẽ được lưu lại và chuyển cho các Stage tiếp theo sử dụng mà không cần Build lại từ đầu. Điều này giúp bảo đảm rằng tất cả các bước kiểm thử và triển khai đều sử dụng đúng một phiên bản đã được tạo ra ở Build Stage.
Có nên chia Build thành thật nhiều Job?
Câu trả lời là không phải lúc nào cũng nên.
Về lý thuyết, việc chia nhỏ thành nhiều Job giúp quy trình rõ ràng hơn. Tuy nhiên, với nhiều hệ thống CI/CD sử dụng Docker, mỗi Job thường phải:
- Khởi tạo một container mới.
- Tải kết quả hoặc cache từ Job trước.
- Thực hiện công việc của mình.
- Lưu lại artifact hoặc cache cho Job kế tiếp.
Nếu chia quá nhiều Job, chi phí khởi tạo container, truyền artifact và đồng bộ cache có thể trở thành một phần đáng kể trong tổng thời gian Pipeline. Vì vậy, nên cân bằng giữa khả năng bảo trì Pipeline và hiệu năng thực thi, thay vì tách nhỏ mọi tác vụ.
Build thành công chưa có nghĩa là phần mềm đã "đạt"
Hoàn thành Build chỉ chứng minh rằng mã nguồn có thể được đóng gói thành công.
Để được triển khai, ứng dụng vẫn phải vượt qua nhiều "cửa kiểm tra" khác như:
- Static Code Analysis
- Dependency Scanning
- Unit Test
- Integration Test
- Security Scan
- Container Image Scan
- Deployment Validation
Chỉ khi tất cả các Stage đều thành công, Pipeline mới tiếp tục đến bước triển khai.
Build Stage chính là nền móng của toàn bộ CI/CD Pipeline. Một quy trình Build được thiết kế tốt sẽ tạo ra artifact nhất quán, có thể tái sử dụng và sẵn sàng cho mọi bước kiểm thử tiếp theo. Đây cũng là lý do các hệ thống DevSecOps hiện đại đầu tư rất nhiều vào việc chuẩn hóa Build, container hóa ứng dụng và quản lý artifact một cách chặt chẽ trước khi phần mềm tiến gần đến môi trường Production.
Attached Files