Continuous Integration (CI, tạm dịch: tích hợp liên tục) hiện nay đã là một trong những best practice trong phát triển phần mềm để đảm bảo phần mềm được deliver nhanh nhất có thể trong khi vẫn đảm bảo được chất lượng phần mềm một cách tốt nhất.
Nói một cách đơn giản, CI là một chu trình build và test được lặp đi lặp lại một cách thường xuyên (ít nhất một lần mỗi ngày) và được thực hiện tự động mỗi lần một developer tích hợp code của họ vào project. Khi có một thay đổi nào đó trong project, một CI server sẽ thực hiện build project đó lại từ đầu và chạy các test suite để đảm bảo rằng thay đổi đó không làm break hệ thống hiện hành.
Nếu build và test thành công, một build artifact (có thể là một file .jar, .war hay một docker image) được tạo ra trong quá trình build sẽ được lưu lại và sẽ được deliver để test trên các môi trường khác nhau. Quá trình deliver cũng có thể được thực hiện tự động, mà còn được gọi là Continuous Delivery (CD), thông thường cũng được thực hiện bởi một CI server.
Lợi ích
Khi được thực thi đúng cách, CI có thể mang lại nhiều lợi ích trong quá trình phát triển phần mềm, chẳng hạn:
- Đảm bảo code quality: CI server sẽ luôn thực hiện code checking và code linting song song với quá trình build để
đảm bảo code của project tuân thủ coding style một cách nhất quán. - Đảm bảo code được test một cách cẩn thận: Các unit test, funtional test sẽ được chạy sau quá trình build để verify những thay đổi đã được thực hiện.
- Phát hiện và sửa lỗi một cách nhanh nhất: Nếu có lỗi xảy ra trong quá trình build và test, developer có thể phát hiện ra và sửa lỗi ngay lập tức.
Những điểm chính trong việc thực hiện CI
Một hệ thống CI có thể được cài đặt với:
- Một project repository được quản lí bởi một version control system (VCS), chẳng hạn Git.
- Một CI server để tự động chạy build và test script mỗi lần có một thay đổi trên project repository, chẳng hạn Jenkins hay Travis CI.
- Một cơ chế gửi feedback, chẳng hạn email hay slack.
Version control
Một vài điểm chính trong việc cấu hình VCS trong việc thực thi CI:
- Nhánh integration: Đây sẽ là nhánh được cấu hình để các developer merge code của họ vào, sau đó CI server sẽ clone code từ nhánh này, thực hiện build và test, tạo artifact. Nhánh này có thể được cấu hình để không cho developer commit hay push code trực tiếp vào vì đây sẽ là nhánh chứa main history và các milestone build cho project.
- Branching policy: Mỗi developer hay một team sẽ thực hiện công việc của họ trên một nhánh riêng được tách từ nhánh integration, với một quy tắc đặt tên riêng được quy định rõ. Mỗi nhánh riêng này cũng được build và test bởi CI server, được review trước khi được merge vào nhánh integration (thông qua cơ chế pull request của Github hay cơ chế code review của Gerrit chẳng hạn).
Automated build
Một CI server sẽ chạy một build script để build project mỗi khi có một thay đổi. Quá trình này diễn ra tự động và không có sự can thiệp của developer. Để đảm bảo tính nhất quán, CI server và developer sẽ sử dụng chung một build script và build script này sẽ được lưu trong VCS. Do đó một build script cũng nên được thiết kễ sao cho nó được chạy một cách đơn giản nhất có thể.
Ví dụ, một build script có thể là một Makefile, developer và CI server sẽ chỉ cần chạy lệnh make để build project.
Cùng với build script, CI server cũng cần phải được setup để có đủ các phần mềm, tài nguyên cần thiết cho quá trình build.
Automated test và code quality
Một build script thông thường cũng sẽ bao gồm luôn việc chạy test sau khi build thành công (ví dụ make test). Các test này có thể là unit test hay functional test. Ngoài ra cũng có hai vấn đề cần lưu ý:
- Code coverage: Là phần trăm source code trong đó nó được chạy hay được cover bởi các test. Phần trăm càng cao nghĩa là code của project được test một cách cẩn thận. Thông thường chúng ta sẽ có một ngưỡng giá trị thích hợp (ví dụ 80%) để nếu code coverage thấp hơn giá trị này, build sẽ được xem như là fail.
- Sanity check: Là việc chạy một phần nhỏ trong toàn bộ các functional test để xác nhận rằng những chức năng cơ bản và những thành phần quan trọng của project không bị ảnh hưởng bởi code mới được tích hợp vào. Ví dụ, các chức năng như login, logout, reset password là những chức năng cơ bản của một trang web, do đó chúng ta cần phải luôn check các chức năng này trước trong mỗi lần chạy test.
Code quality cũng là một thành phần quan trọng của project và nó có thể được thực hiện song song với quá trình build. Code quality check ở đây có thể nói đến như check coding style, check duplicate code, check too long function, v.v. Điều này sẽ tùy thuộc vào project và quy định của từng team trong mỗi công ty.
Feedback
Sau khi CI server build và test, dù success hay fail, thì một feedback vẫn phải được gửi cho các developer có liên quan để họ có được những thông tin cần thiết như test results, code coverage, code quality, v.v. Feedback có thể đươc gửi qua email hay slack.
Github và Travis CI
Để có thể làm quen với CI, Github và Travis CI chính là hai service dễ tiếp cận để bắt đầu. Chúng ta có thể setup một project đơn giản bằng một ngôn ngữ tùy thích, thực hiện build (đối với các ngôn ngữ biên dịch) và test, push code lên Github và trigger một build trên Travis CI.
Travis CI Documentation là nơi mà chúng ta có thể bắt đầu để làm quen với CI service này.
TL;DR
Trên đây là những ghi chép tổng quan về các điểm chính về CI, thực tế sẽ có nhiều vấn đề hơn. Việc có một hệ thống CI giúp chúng ta giảm thiểu bug trong quá trình phát triển phần mềm, đảm bảo code quality cho project. Đồng thời việc fix bug, refactor code cho project cũng trở nên dễ thở hơn so với các mô hình phát triển phần mềm truyền thống.
Build và test là hai giai đoạn quan trọng trong việc thực thi CI, chúng cần được thực hiện đúng cách và cẩn thận để mang lại lợi ích cho quá trình phát triển phần mềm.
CodeBin 