Continuous Integration

Continuous Integration Là Gì

Tích hợp liên tục (CI) là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. Mỗi ngày, các thành viên đều phải theo dõi và phát triển công việc của họ ít nhất một lần. Việc này sẽ được một nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành kiểm thử truy hồi để phát hiện lỗi nhanh nhất có thể. Cả nhóm thấy rằng phương pháp tiếp cận này giúp giảm bớt vấn đề về tích hợp hơn và cho phép phát triển phần mềm gắn kết nhanh hơn.

Vòng đời phát triển phần mềm theo phương pháp CI

Tại sao nên dùng CI ?

Sử dụng phương pháp CI giúp cho hệ thống luôn đảm bảo là build được và chạy đúng (do phải pass qua toàn bộ test case). Mặt khác các công đoạn test sẽ được hệ thống CI server thực hiện tự dộng giúp cho ta có thể dễ dàng biết được tình trạng của một branch, một commit nào đó và không cần lấy source về test thử. Do đó tốc độ phát triển được tăng lên. Đây cũng là lý do mà nhiều team phát triển theo mô hình Agile lựa chọn phương pháp này.

Hiện tại các công ty lớn thường triển khai các hệ thống CI cho riêng mình hoặc sử dụng dịch vụ của hãng thứ 3. Một số framework được sử dụng phổ biến như:

• Team Foundation Server - Microsoft
• TeamCity - Jet Brains
• Hudson
• Jenkin
• Travis CI
• GitLab CI

Ngoài ra còn nhiều dịch vụ khác.

Workflow của CI

Workflow của phương pháp CI được chia thành 6 bước như sau:

Bước 1 Các người phát triển sẽ đưa phần source mà họ đã thay đổi lên Source Control Server. Khi đó Source Control Server sẽ thông báo với CI Server là có bản source mới.

Bước 2 CI Server lấy source mới về

Bước 3, 4 & 5 CI Server sẽ build, test và cập nhật lại trạng thái build của bản source đó.

Bước 6 CI Server sẽ thông báo đến người quản lý và các người phát triển về tình trạng của bản code mới.

Một hệ thống CI thông thường thực hiện những tác vụ sau:

1. Phát hiện thay đổi trong source code repository (xuất hiện commit mới)
2. Phân tích chất lượng source code
3. Thực hiện build
4. Chạy toàn bộ unit test
5. Chạy toàn bộ integration test
6. Sinh ra những tạo tác có thể triển khai được, gọi là deployable artifact
7. Có thể, deploy những artifact này và thực hiện những kiểm thử khác nếu cần

Nếu một trong những bước trên không thành công:

• Tuỳ thuộc vào mức độ nghiêm trọng, việc tích hợp có thể dừng lại hoặc đi tiếp
• Kết quả tích hợp được thông báo tới nhóm phát triển qua email, hệ thống chat. Thông qua sour code repository, CI có thể nhận biết cá nhân đã thực hiện việc commit gây ra lỗi trong việc tích hợp.
• Nhóm phát triển hoặc cá nhân thực hiện commit thực hiện sửa lỗi và commit
• CI phát hiện thay đổi trong source code repository và thực hiện lại những bước trên

Trong những tác vụ trên, tác vụ 1, 3, 6 thực sự rất dễ thực hiện và được hỗ trợ bởi hầu hết những công cụ CI hiện có trên thị trường. Những tác vụ 2, 4, 5 không đơn giản chỉ là sự hỗ trợ của công cụ, tư tưởng và cách thực hiện phía sau quan trọng hơn rất nhiều; chúng ta sẽ bàn về những vấn đề này ở những bài viết sau. Tác vụ 7 lại liên quan tới một hệ thống CD (Continuos Deployment – triển khai liên tục) với tư tưởng giống với CI nhưng dưới góc độ “triển khai” và lại phụ thuộc vào tần suất release của sản phẩm và độ phức tạp của môi trường nên không hẳn là một công cụ tiên quyết trong việc thực hành Agile.

Tuy vậy, nhiều nhóm thực hành Agile vẫn lựa chọn việc triển khai CI và CD đồng thời bởi một trong những best practice của CI là đảm bảo môi trường đồng nhất (hoặc gần giống nhất) giữa môi trường kiểm thử (tích hợp) và môi trường production.

Chúng ta dễ dàng nhận thấy ưu điểm của commit build so với daily build vì cô lập được thay đổi theo từng commit khiến việc xử lý xung đột đơn giản hơn. Tuy vậy, thời gian để CI thực hiện toàn bộ 7 tác vụ trên có thể rất nhiều với một số môi trường của dự án khiến việc này không khả thi; nên nhiều nhóm thực hành Agile vẫn lựa chọn daily build. Tôi là một người theo trường phái commit build và luôn cố gắng duy trì CI theo cách này. Với những dự án phức tạp, tôi thường sử dụng nhiều build agent để thực hiện việc tích hợp song song với những commit cùng thời điểm. Một giải pháp khác là, lược bỏ những tác vụ không cần thiết (ví dụ tác vụ 7) để vẫn thực hiện việc tích hợp với từng commit và thực hiện một “long build” vào cuối ngày.

Hiện nay có rất nhiều công cụ CI cho phép nhóm thực hành Agile lựa chọn với những tác vụ cơ bản như trên, phổ biến nhất có lẽ là Jenkins – hệ thống mã nguồn mở với rất nhiều plugin phù hợp với nhiều điều kiện hệ thống khác nhau. Tôi cũng là một kẻ hâm mộ Jenkins nhưng lại thường sử dụng những công cụ khác khi có thể, chỉ bởi giao diện của Jenkins thì quá tệ và cũng vì cónhiều người sử dụng quá.