Tích hợp liên tục - Yêu cầu
Sau đây là danh sách các yêu cầu quan trọng nhất đối với Tích hợp liên tục.
Check-In Regularly- Thực tiễn quan trọng nhất để tích hợp liên tục hoạt động bình thường là thường xuyên đăng ký vào đường trục hoặc đường chính của kho mã nguồn. Việc đăng ký mã phải diễn ra ít nhất một vài lần một ngày. Kiểm tra thường xuyên mang lại rất nhiều lợi ích khác. Nó làm cho các thay đổi nhỏ hơn và do đó ít có khả năng phá vỡ cấu trúc hơn. Nó có nghĩa là phiên bản mới nhất của phần mềm cần hoàn nguyên sẽ được biết khi có lỗi xảy ra trong bất kỳ bản dựng tiếp theo nào.
Nó cũng giúp có kỷ luật hơn trong việc tái cấu trúc mã và tuân theo những thay đổi nhỏ để duy trì hành vi. Nó giúp đảm bảo rằng các thay đổi làm thay đổi nhiều tệp ít có khả năng xung đột với công việc của người khác. Nó cho phép các nhà phát triển khám phá nhiều hơn, thử các ý tưởng và loại bỏ chúng bằng cách hoàn nguyên về phiên bản cam kết cuối cùng.
Create a Comprehensive Automated Test Suite- Nếu bạn không có một bộ kiểm tra tự động toàn diện, bản dựng vượt qua chỉ có nghĩa là ứng dụng có thể được biên dịch và lắp ráp. Mặc dù đối với một số nhóm, đây là một bước tiến lớn, nhưng điều cần thiết là phải có một số cấp độ kiểm tra tự động để đảm bảo rằng ứng dụng của bạn đang thực sự hoạt động.
Thông thường, có 3 loại kiểm tra được thực hiện trong Tích hợp liên tục là unit tests, component testsvà acceptance tests.
Bài kiểm tra đơn vị được viết để kiểm tra hành vi của các phần nhỏ ứng dụng của bạn một cách riêng biệt. Chúng thường có thể được chạy mà không cần khởi động toàn bộ ứng dụng. Chúng không đánh vào cơ sở dữ liệu (nếu ứng dụng của bạn có), hệ thống tệp hoặc mạng. Họ không yêu cầu ứng dụng của bạn phải chạy trong một môi trường giống như sản xuất. Các bài kiểm tra đơn vị sẽ chạy rất nhanh - toàn bộ bộ ứng dụng của bạn, ngay cả đối với một ứng dụng lớn, sẽ có thể chạy trong vòng chưa đầy mười phút.
Kiểm tra thành phần kiểm tra hành vi của một số thành phần trong ứng dụng của bạn. Giống như các bài kiểm tra đơn vị, chúng không phải lúc nào cũng yêu cầu khởi động toàn bộ ứng dụng. Tuy nhiên, chúng có thể tấn công cơ sở dữ liệu, hệ thống tệp hoặc các hệ thống khác (có thể bị khai tử). Kiểm tra thành phần thường mất nhiều thời gian hơn để chạy.
Keep the Build and Test Process Short - Nếu mất quá nhiều thời gian để xây dựng mã và chạy các bài kiểm tra đơn vị, bạn sẽ gặp phải các vấn đề sau.
Mọi người sẽ ngừng xây dựng đầy đủ và sẽ chạy các bài kiểm tra trước khi họ đăng ký. Bạn sẽ bắt đầu nhận được nhiều bản dựng thất bại hơn.
Quá trình Tích hợp liên tục sẽ mất nhiều thời gian đến mức có nhiều lần cam kết sẽ diễn ra vào thời điểm bạn có thể chạy lại bản dựng, vì vậy bạn sẽ không biết đăng ký nào đã phá vỡ bản dựng.
Mọi người sẽ ít đăng ký hơn vì họ phải ngồi chờ đợi phần mềm được xây dựng và chạy thử nghiệm.
Don’t Check-In on a Broken Build- Sai lầm lớn nhất của việc tích hợp liên tục là đăng ký một bản dựng bị hỏng. Nếu bản dựng bị hỏng, các nhà phát triển chịu trách nhiệm đang đợi để sửa nó. Họ xác định nguyên nhân gây ra vỡ càng sớm càng tốt và sửa chữa nó. Nếu chúng tôi áp dụng chiến lược này, chúng tôi sẽ luôn ở vị trí tốt nhất để tìm ra nguyên nhân gây ra sự cố và khắc phục nó ngay lập tức.
Nếu một trong các đồng nghiệp của chúng tôi đã thực hiện đăng ký và kết quả là đã làm hỏng bản dựng, thì để có cơ hội tốt nhất để sửa chữa nó, họ sẽ cần phải giải quyết vấn đề một cách rõ ràng. Khi quy tắc này bị phá vỡ, chắc chắn sẽ mất nhiều thời gian hơn để bản dựng được sửa. Mọi người quen với việc nhìn thấy tòa nhà bị hỏng, và rất nhanh chóng bạn sẽ rơi vào tình trạng tòa nhà luôn bị hỏng.
Always Run All Commit Tests Locally Before Committing- Luôn đảm bảo rằng các bài kiểm tra được thiết kế cho ứng dụng được chạy trước trên một máy cục bộ trước khi chạy chúng trên máy chủ CI. Điều này là để đảm bảo các trường hợp kiểm thử đúng được viết và nếu có bất kỳ lỗi nào trong quá trình CI thì đó là do kết quả kiểm tra không thành công.
Take Responsibility for All Breakages that Result from Your Changes- Nếu bạn thực hiện một thay đổi và tất cả các bài kiểm tra bạn đã viết đều vượt qua, nhưng những bài kiểm tra khác phá vỡ, bản dựng vẫn bị hỏng. Thông thường, điều này có nghĩa là bạn đã đưa vào ứng dụng một lỗi hồi quy. Bạn có trách nhiệm - bởi vì bạn đã thực hiện thay đổi - sửa chữa tất cả các bài kiểm tra không đạt do các thay đổi của bạn. Trong bối cảnh của CI, điều này có vẻ hiển nhiên, nhưng thực ra nó không phải là một thực tế phổ biến trong nhiều dự án.