Tích hợp liên tục: tần số nào?

Tôi đã luôn khởi chạy các bản dựng sau mỗi lần cam kết, nhưng trong dự án mới này, các kiến ​​trúc sư chỉ yêu cầu tôi thay đổi tần suất thành "một bản dựng cứ sau 15 phút" và tôi không thể hiểu tại sao đó là lý do chính đáng so với " xây dựng trên từng cam kết ".

Trước hết, một số chi tiết:

• Dự án Objective-C (iOS 5)
• 10 nhà phát triển
• mỗi bản dựng thực sự mất ~ 1 phút và bao gồm bản dựng và kiểm tra đơn vị.
• máy chủ tích hợp là máy Mac Mini, vì vậy sức mạnh tính toán không thực sự là vấn đề ở đây
  • chúng tôi sử dụng Jenkins với plugin XCode

Lập luận của tôi là nếu bạn xây dựng ở mỗi lần xác nhận, bạn có thể thấy ngay những gì đã sai và sửa trực tiếp lỗi của mình mà không làm phiền các nhà phát triển khác quá thường xuyên. Thêm vào đó, người kiểm tra của chúng tôi ít bị làm phiền bởi các lỗi UT theo cách này. Lập luận của ông là các nhà phát triển sẽ bị ngập trong các thư "lỗi xây dựng" (điều này không hoàn toàn đúng, vì Jenkins có thể được cấu hình để gửi thư chỉ cho bản dựng bị hỏng đầu tiên) và các số liệu không thể được thực hiện đúng nếu tần số của bản dựng quá cao.

Vì vậy, ý kiến ​​của bạn về điều này là gì?

Thất bại nhanh là một nguyên tắc tốt - bạn càng sớm biết bản dựng bị hỏng, thì càng sớm xác định được cam kết vi phạm và bản dựng đã được sửa.

Xây dựng trên mỗi cam kết là điều đúng đắn để làm.

Việc xây dựng cứ sau 15 phút có thể là vô nghĩa nếu dự án có khối lượng cam kết lớn trong khung thời gian như vậy - việc theo dõi các cam kết xấu sẽ mất nhiều thời gian hơn và có thể khó xác định (một người cũng có thể ở trong tình huống nhiều cam kết có những điều khác nhau phá vỡ công trình). Ngoài ra còn có khả năng là trong thời gian yên tĩnh (thời gian ban đêm?) Bạn sẽ xây dựng lại mặc dù không có thay đổi nào được thực hiện.

Nếu bản dựng bị hỏng thường xuyên đến mức gây ra sự cố, thì câu trả lời là phải giáo dục lại nhóm về tầm quan trọng của việc không phá vỡ bản dựng và trong các kỹ thuật đảm bảo điều này không xảy ra (thường xuyên tìm nạp, nhảy checkin, biên dịch và chạy thử nghiệm đơn vị v.v ...).

Thực sự không có điểm nào trong việc xây dựng cứ sau 15 phút nếu không có gì thay đổi. Nhưng cũng không có nhược điểm, afaik, jenkins sẽ chỉ e-mail về thất bại và sau đó thành công và không phải tất cả mọi thứ ở giữa (ví dụ 10 thất bại).

Chúng tôi làm điều đó trên mỗi cam kết. Tuy nhiên, chúng tôi thăm dò kho lưu trữ cứ sau mười lăm phút và kiểm tra các thay đổi, có thể đó là những gì các đồng nghiệp đang đề cập đến.

Bạn mong đợi 10 dev của bạn sẽ cam kết nhiều hơn một lần trong mười lăm phút? Nghe có vẻ như là một ước tính cao. 10 dev có nghĩa là cứ sau 150 phút, cùng một người lại cam kết, vậy là 2,5 giờ. Vì vậy, trong ngày trung bình của bạn mỗi dev cam kết 3 lần. Cá nhân tôi thực hiện một cam kết ~ 2 ngày ... đôi khi nhiều hơn đôi khi ít hơn.

Nó sẽ tràn ngập các nhà phát triển với thư nhiều hơn nếu cứ sau 15 phút. Đó là bởi vì nó sẽ không biết chắc chắn ai đã phá vỡ bản dựng và do đó gửi nhiều người hơn.

Đối với các số liệu, nếu đó thực sự là một vấn đề mà tôi không thể biết được vì tôi không biết họ nghĩ gì về vấn đề này, thì bạn luôn có thể tạo một công việc khác để thu thập các số liệu.

Có lẽ yêu cầu sẽ là "xây dựng nhiều nhất một lần trong 15 phút". Điều này có thể có ý nghĩa đối với các dự án có hoạt động cam kết rất thường xuyên (nghĩa là nhiều lần cam kết trong vòng vài phút) và có lẽ thời gian xây dựng dài. Tất nhiên nó cũng phụ thuộc vào cách sử dụng các bản dựng. Đối với những người thử nghiệm, có thể hơi khó hiểu khi có nhiều bản dựng trong vòng 15 phút ...

Nhưng tôi đồng ý rằng nó không có ý nghĩa để xây dựng nếu không có gì thay đổi.

Một số nhà phát triển muốn được phép thực hiện các cam kết theo cách mà các tệp thuộc một thay đổi chức năng không được cam kết trong một quy trình nguyên tử duy nhất. Họ cần hai hoặc ba phút để thực hiện một "cam kết hợp lý", bao gồm một số "cam kết vật lý". Đây thường là trường hợp khi nhà phát triển của bạn trực tiếp cam kết vào một kho lưu trữ trung tâm, không sử dụng DVCS.

Trong trường hợp này, có thể là một ý tưởng tốt để cho máy chủ CI của bạn đợi một thời gian sau lần xác nhận cuối cùng trước khi bắt đầu xây dựng mới. Nhưng 15 phút dường như là một con số rất cao, 5 phút hoặc ít hơn là đủ.

Hoặc, tốt hơn (!), Cố gắng hướng dẫn các nhà phát triển của bạn chỉ hoạt động trong các phần nhỏ, chỉ một việc tại một thời điểm, làm cho việc thực hiện các cam kết vật lý "hoàn thành chức năng" dễ dàng hơn nhiều. Sau đó, một bản dựng sau mỗi lần cam kết sẽ hoạt động dường như.

Ngay cả khi bạn đã thiết lập Jenkins để xây dựng dựa trên cam kết kiểm soát nguồn cho dự án hoặc bất kỳ phụ thuộc nào của dự án, điều này cũng không ngăn nhà phát triển triển khai vào kho lưu trữ giả mà không cam kết kiểm soát nguồn trước. Nếu họ triển khai thay đổi API không phối hợp hoặc lỗi phụ thuộc vào kho lưu trữ giả, điều này có thể phá vỡ bản dựng của bạn mà không kích hoạt công việc Jenkins. Cá nhân tôi muốn biết về điều này càng sớm càng tốt.

Lý tưởng nhất là bạn sẽ xây dựng cho mọi cam kết và cũng theo lịch trình để kiểm tra các tình huống như tôi vừa mô tả. Điều này về mặt khái niệm có nghĩa là bạn xây dựng ít nhất 15 phút một lần .

Nếu bạn có các công việc Jenkins được thiết lập để chạy trên các triển khai nhân tạo phụ thuộc (và nếu bạn làm ... Bravo), bạn có thể kiểm tra bản dựng theo lịch trình nếu các bài kiểm tra đơn vị của bạn là vững chắc (có nghĩa là chúng không kiểm tra các phụ thuộc) và của bạn kiểm tra tích hợp / chức năng không phải là một phần của công việc Jenkins.

Đối với vấn đề "lũ lụt với email", tôi nói rằng việc tràn ngập email trên một bản dựng bị hỏng là một điều tốt. Hãy chắc chắn rằng bạn buộc các nhà phát triển trả lời email bằng một mô tả và bạn sẽ thấy các bản dựng bị hỏng của mình đi xuống, hãy tin tôi.

Bạn nói rằng bạn không thể hiểu lý do của họ, vì vậy bạn phải hỏi họ. Đừng chỉ đoán những gì họ muốn và cố gắng thực hiện điều đó, và chắc chắn không chỉ thực hiện những gì họ yêu cầu mà không hiểu lý do tại sao họ yêu cầu.

Điều đó nói rằng, để trả lời câu hỏi chung, nó phụ thuộc vào triết lý phát triển bạn sử dụng. Nếu mọi cam kết dự kiến ​​sẽ hoạt động, thì mọi cam kết sẽ được kiểm tra. Nếu bạn sử dụng DVCS với triết lý rằng mỗi lần đẩy nên hoạt động, thì hãy kiểm tra mọi lần đẩy.

Nói chung, tốt hơn là nói với mọi người những điều họ không biết, sau đó lặp lại những gì họ biết. Ví dụ: nếu họ muốn giảm số lượng email dư thừa họ nhận được, hãy điều chỉnh cài đặt email, không phải tần suất xây dựng.