Làm thế nào có thể quy mô tích hợp liên tục cho các dự án / nhóm rất lớn?

Theo truyền thống, các hệ thống CI chỉ giám sát chất lượng của mã trong một nhánh tích hợp, báo hiệu khi xảy ra hồi quy. Sự can thiệp của con người là cần thiết để sửa chữa.

Khi số lượng nhà phát triển làm việc trên cùng một chi nhánh làm tăng nguy cơ vỡ / tắc nghẽn tăng lên. Cuối cùng, một điểm đạt được trong đó trung bình vào thời điểm một sự cố được khắc phục, một điểm mới xuất hiện tiến bộ trên nhánh trở nên không đáng kể.

Việc chia thành nhiều nhóm, mỗi nhóm làm việc trên một nhánh tích hợp riêng biệt sẽ được sáp nhập vào một thời điểm sau đó có thể giúp ích, nhưng kéo dài đáng kể thời gian dự án, vì nó chỉ đơn giản là trì hoãn sự tích hợp cần thiết cho một thời điểm sau trong khi thêm bộ lọc / tiếng ồn / kỹ thuật liên quan đến sự tích hợp một phần từ sự hợp nhất chi nhánh cá nhân. Chi phí cũng tăng do thiết lập CI cho từng chi nhánh, mỗi chi nhánh có tài nguyên xây dựng / QA riêng, v.v. Và chất lượng tổng thể không nhất thiết phải tốt hơn.

Khả năng mở rộng là, tốt nhất, đáng ngờ.

Có một phương pháp để làm cho các dự án lớn như vậy thực sự quy mô?

Có, nhưng đó là bằng cách ngăn chặn những điều bạn đề cập trong câu hỏi của bạn càng nhiều càng tốt. Bạn đúng rằng chỉ có rất nhiều nhà phát triển có thể làm việc trên cùng một mã trước khi mọi thứ trở nên không thể quản lý được. Bạn cần ai đó hoặc một cái gì đó có cái nhìn tổng quan về tất cả các thay đổi và đảm bảo tích hợp hoạt động tốt và hồi quy không xảy ra. Điều này khó mở rộng nếu mọi thứ xảy ra trong một kho lưu trữ.

Trước khi bắt đầu bất kỳ công việc nào, bạn cần tách chức năng theo cách sao cho mọi thứ có thể được tích hợp sau này với ít hoặc không cần nỗ lực. Điều này có nghĩa là bạn muốn chia chức năng thành các phần độc lập hoặc ít nhất có ít phụ thuộc nhất có thể. Làm thế nào bạn làm điều này phụ thuộc rất nhiều vào sản phẩm bạn đang phát triển. Trước đây, chức năng phân tách được thực hiện bằng cách tạo các thư viện khác nhau. Nhược điểm của việc này là bạn cần một phương pháp tốt để quản lý các thư viện đó. Các phiên bản cũ của Windows chẳng hạn có một hệ thống quản lý thư viện tồi tệ gây ra DLL Hell khét tiếng . Ngày nay, các dịch vụ vi mô là (trở thành) một cách phổ biến để làm điều này, mặc dù điều này cũng có nhược điểm (ví dụ: chi phí liên lạc, nhiều dịch vụ hơn để giám sát)

Nếu việc phân tách dựa trên chức năng là khó khăn, một lựa chọn khác có thể là tách thời gian phát triển. Thay vì nhiều nhóm làm việc đồng thời trên nhiều tính năng khác nhau, bạn có 1 nhóm chỉ hoạt động trên 1 hoặc một vài tính năng.

Khi không thể tách công việc, bạn sẽ cần các công cụ và bài kiểm tra để đảm bảo mọi thứ phù hợp. Đơn vị tự động và kiểm thử tích hợp có thể là một trợ giúp lớn ở đây, nhưng cuối cùng sẽ có giới hạn về mức độ lớn của một dự án hoặc nhóm để có thể thực hiện được.

Khi số lượng nhà phát triển làm việc trên cùng một chi nhánh làm tăng nguy cơ vỡ / tắc nghẽn tăng lên. Cuối cùng, một điểm đạt được trong đó trung bình tại thời điểm một sự cố được cố định, một điểm mới xuất hiện

Trong khi phần đầu của câu có lẽ đúng về mặt thống kê, tôi không đồng ý với phần thứ hai.

CI và các nhánh tích hợp không thể đánh bại GIGO (rác trong rác) Nếu các nhà phát triển không có kỷ luật thì bạn sẽ kết thúc trong một nhánh bị tạm dừng, nhưng các thử nghiệm nhánh tích hợp chỉ nên đóng vai trò là rào cản lat, chứ không phải đầu tiên.

Các nhà phát triển nên sử dụng các tiêu chuẩn mã hóa phù hợp, đánh giá mã, kiểm tra đơn vị địa phương và có thể kiểm tra nhánh trước tích hợp để làm cho các xung đột ít xảy ra hơn.

Tôi đang làm việc hàng ngày trên một hệ thống như vậy với hàng trăm người đóng góp và thật ngạc nhiên khi thấy nó bị treo.

Tôi không có đủ dữ liệu nhưng có thể đúng là chi phí cao, mặt khác, rất khó để đánh giá chi phí thay thế của tích hợp muộn và lỗi.

Một cách tiếp cận khác là chuyển sang một hệ thống CI phi truyền thống khác, có khả năng ngăn chặn hồi quy bằng cách xác định và từ chối các thay đổi ứng viên vi phạm trước khi cam kết thay vì phát hiện hồi quy và chờ phục hồi trong khi phát triển trên chi nhánh bị chặn. Tôi thích gọi hệ thống như vậy là hệ thống CI không chặn .

Đơn giản chỉ cần tăng các yêu cầu xác minh trước cam kết do nhà phát triển thực hiện trong nỗ lực giảm hồi quy chi nhánh là không đủ để đảm bảo như vậy. Nó thực sự có thể gây ra sự gia tăng tốc độ hồi quy : thời gian xác minh lâu hơn => số lượng thay đổi được xác minh đồng thời cao hơn (do đó không tính toán lẫn nhau) => nguy cơ xung đột và can thiệp chức năng cao hơn. Tôi đang giải thích điều này chi tiết hơn một chút trong phần Mở rộng phạm vi xác minh trước khi cam kết sẽ làm tăng huyền thoại ổn định chi nhánh của chúng tôi .

Tất nhiên, công cụ CI cũng cần có khả năng hoạt động ở quy mô. Và các công cụ như vậy tồn tại, xem Có công cụ CI nào đảm bảo không có hồi quy ở mức chất lượng chi nhánh không?

^{Tiết lộ: Tôi liên kết với công ty được đề cập trong các liên kết trên.}