Xử lý nhiều nhánh trong tích hợp liên tục

Tôi đang giải quyết vấn đề mở rộng quy mô CI tại công ty của mình và đồng thời cố gắng tìm ra cách tiếp cận nào để thực hiện khi nói đến CI và nhiều chi nhánh. Có một câu hỏi tương tự tại stackoverflow, Nhiều nhánh tính năng và tích hợp liên tục . Tôi đã bắt đầu một cái mới vì tôi muốn thảo luận nhiều hơn và đưa ra một số phân tích trong câu hỏi.

Cho đến nay, tôi thấy rằng có 2 cách tiếp cận chính mà tôi có thể thực hiện (hoặc có thể một số cách khác ???).

• Nhiều nhóm công việc (nói về Jenkins / Hudson tại đây) cho mỗi nhánh
  • Viết công cụ để quản lý các công việc phụ
    • Tạo / sửa đổi / xóa hàng loạt Công việc
    • Cài đặt tùy chỉnh cho từng công việc trên mỗi nhánh (url SCM, bản sao quản lý dep)
    • Một số ví dụ về những người giải quyết vấn đề này bằng các công cụ shell, ant scripts và Jenkins CLI. Xem:
      1. http://jenkins.361315.n4.nabble.com/Multiple-bragets-best-practice-td2306578.html
      2. http://jenkins.361315.n4.nabble.com/Is-it-possible-to-handle-multiple-braffs-where-some-jobs-should-run-on-each-one-without-duplicatin-td954729. html
      3. http://jenkins.361315.n4.nabble.com/Parallel-development-with-bragets-td1013013.html
      4. Định cấu hình hoặc tạo công việc hudson tự động
  • Sẽ gây ra nhiều tải hơn trên cụm CI của bạn
  • Chu kỳ phản hồi dành cho nhà phát triển chậm lại (nếu cơ sở hạ tầng không thể xử lý tải mới)
• Nhiều nhóm công việc trên 2 nhánh (nhà phát triển và ổn định)
  • Quản lý hai bộ theo cách thủ công (nếu bạn thay đổi giới hạn của một công việc thì hãy đảm bảo thay đổi trong nhánh khác)
    • PITA nhưng ít nhất phải quản lý rất ít
  • Các chi nhánh bổ sung khác sẽ không nhận được bộ thử nghiệm đầy đủ trước khi chúng được chuyển sang nhà phát triển
  • Các nhà phát triển không hài lòng. Tại sao một nhà phát triển nên quan tâm đến các vấn đề mở rộng CI. Anh ấy có một yêu cầu đơn giản, khi tôi rẽ nhánh, tôi muốn kiểm tra mã của mình. Đơn giản.

Vì vậy, có vẻ như nếu tôi muốn cung cấp cho các nhà phát triển CI cho các nhánh tùy chỉnh của riêng họ, tôi cần công cụ đặc biệt cho Jenkins (API hoặc shellcripts hoặc thứ gì đó?) Và xử lý mở rộng quy mô. Hoặc tôi có thể yêu cầu họ hợp nhất thường xuyên hơn với DEV và sống mà không có CI trên các nhánh tùy chỉnh. Bạn sẽ chọn cái nào hoặc có những lựa chọn nào khác?

Khi bạn nói về việc mở rộng CI, bạn thực sự đang nói về việc mở rộng việc sử dụng máy chủ CI của bạn để xử lý tất cả các nhánh tính năng cùng với dòng chính của bạn. Ban đầu, đây có vẻ là một cách tiếp cận tốt vì các nhà phát triển trong một chi nhánh có được tất cả các lợi thế của kiểm thử tự động mà các công việc CI bao gồm. Tuy nhiên, bạn gặp phải vấn đề trong việc quản lý các công việc máy chủ CI (như bạn đã phát hiện ra) và quan trọng hơn, bạn không thực sự làm CI. Có, bạn đang sử dụng máy chủ CI, nhưng bạn không liên tục tích hợp mã từ tất cả các nhà phát triển của mình.

Thực hiện CI thực sự có nghĩa là tất cả các nhà phát triển của bạn đang cam kết thường xuyên với dòng chính. Nói thì dễ nhưng cái khó là làm mà không làm vỡ ứng dụng của bạn. Tôi thực sự khuyên bạn nên xem Phân phối liên tục , đặc biệt là phần Giữ cho ứng dụng của bạn có thể phát hành trong Chương 13: Quản lý các thành phần và sự phụ thuộc . Những điểm chính là:

• Ẩn chức năng mới cho đến khi hoàn thành ( Chuyển đổi tính năng AKA ).
• Thực hiện tất cả các thay đổi tăng dần như một loạt các thay đổi nhỏ, mỗi thay đổi đều có thể thay đổi được.
• Sử dụng nhánh theo trừu tượng để thực hiện các thay đổi quy mô lớn đối với cơ sở mã.
• Sử dụng các thành phần để tách các phần của ứng dụng thay đổi theo các tỷ lệ khác nhau.

Chúng khá tự giải thích ngoại trừ phân nhánh bằng trừu tượng. Đây chỉ là một thuật ngữ ưa thích cho:

1. Tạo một phần trừu tượng cho phần hệ thống mà bạn cần thay đổi.
2. Cấu trúc lại phần còn lại của hệ thống để sử dụng lớp trừu tượng.
3. Tạo một triển khai mới, không phải là một phần của đường dẫn mã sản xuất cho đến khi hoàn tất.
4. Cập nhật lớp trừu tượng của bạn để ủy quyền cho việc triển khai mới của bạn.
5. Loại bỏ triển khai cũ.
6. Loại bỏ lớp trừu tượng nếu nó không còn phù hợp.

Đoạn sau từ phần Nhánh, Luồng và Tích hợp Liên tục trong Chương 14: Kiểm soát Phiên bản Nâng cao tóm tắt các tác động.

Cách tiếp cận gia tăng chắc chắn đòi hỏi nhiều kỷ luật và cẩn thận hơn - và thực sự là sáng tạo hơn - hơn là tạo ra một chi nhánh và lao vào tái cấu trúc và phát triển chức năng mới. Nhưng nó làm giảm đáng kể nguy cơ các thay đổi của bạn phá vỡ ứng dụng và sẽ tiết kiệm rất nhiều thời gian cho bạn và nhóm của bạn khi hợp nhất, sửa lỗi và đưa ứng dụng của bạn vào trạng thái có thể triển khai.

Cần phải chuyển đổi tâm trí khá nhiều để từ bỏ các nhánh tính năng và bạn sẽ luôn nhận được sự phản kháng. Theo kinh nghiệm của tôi, sự kháng cự này dựa trên việc các nhà phát triển không cảm thấy an toàn khi cam kết mã trên dòng chính và đây là một mối quan tâm hợp lý. Ngược lại, điều này thường bắt nguồn từ việc thiếu kiến ​​thức, sự tự tin hoặc kinh nghiệm với các kỹ thuật được liệt kê ở trên và có thể do sự thiếu tự tin với các bài kiểm tra tự động của bạn. Vấn đề trước đây có thể được giải quyết với sự hỗ trợ của nhà phát triển và đào tạo. Vấn đề thứ hai là một vấn đề khó giải quyết hơn nhiều, tuy nhiên việc phân nhánh không cung cấp thêm bất kỳ sự an toàn thực sự nào, nó chỉ giải quyết vấn đề cho đến khi các nhà phát triển cảm thấy đủ tự tin với mã của họ.

Tôi sẽ thiết lập các công việc riêng biệt cho từng chi nhánh. Tôi đã làm điều này trước đây và không khó để quản lý và thiết lập nếu bạn đã thiết lập đúng Hudson / Jenkins. Một cách nhanh chóng để tạo nhiều công việc là sao chép từ một công việc hiện có có các yêu cầu tương tự và sửa đổi chúng nếu cần. Tôi không chắc liệu bạn có muốn cho phép mỗi nhà phát triển thiết lập công việc của riêng họ cho các chi nhánh của riêng họ hay không, nhưng việc một người (tức là người quản lý bản dựng) quản lý thì không nhiều. Khi các nhánh tùy chỉnh đã được hợp nhất thành các nhánh ổn định, các công việc tương ứng có thể được gỡ bỏ khi chúng không còn cần thiết nữa.

Nếu lo lắng về tải trên máy chủ CI, bạn có thể thiết lập các phiên bản CI riêng biệt hoặc thậm chí là các nô lệ riêng biệt để giúp cân bằng tải trên nhiều máy chủ. Đảm bảo rằng máy chủ mà bạn đang chạy Hudson / Jenkins là đủ. Tôi đã sử dụng Apache Tomcat và chỉ cần đảm bảo rằng nó có đủ bộ nhớ và sức mạnh xử lý để xử lý hàng đợi xây dựng.

Điều quan trọng là phải rõ ràng về những gì bạn muốn đạt được bằng cách sử dụng CI và sau đó tìm ra cách để thực hiện nó mà không cần nhiều nỗ lực thủ công hoặc trùng lặp. Không có gì sai khi sử dụng các công cụ hoặc tập lệnh bên ngoài khác được thực thi bởi máy chủ CI của bạn để giúp đơn giản hóa quy trình quản lý bản dựng tổng thể của bạn.

Tôi sẽ chọn dev + các nhánh ổn định. Và nếu bạn vẫn muốn các chi nhánh tùy chỉnh và sợ tải, thì tại sao không chuyển các chi nhánh tùy chỉnh này lên đám mây và để các nhà phát triển tự quản lý, ví dụ: http://cloudbees.com/dev.cb Đây là công ty mà Kohsuke hiện đang ở . Ngoài ra còn có Công cụ Eclipse, vì vậy nếu bạn đang sử dụng Eclipse, bạn sẽ có nó được tích hợp chặt chẽ ngay vào dev env.

Trên thực tế, điều thực sự có vấn đề là xây dựng sự cô lập với các nhánh tính năng. Trong công ty của chúng tôi, chúng tôi có một tập hợp các dự án maven riêng biệt, tất cả đều là một phần của phân phối lớn hơn. Các dự án này được duy trì bởi các nhóm khác nhau nhưng đối với mỗi bản phân phối, tất cả các dự án cần được phát hành. Một featurebranch bây giờ có thể chồng chéo từ dự án này sang dự án khác và đó là khi việc cô lập xây dựng trở nên khó khăn. Có một số giải pháp chúng tôi đã thử:

• tạo kho lưu trữ ảnh chụp nhanh riêng biệt trong nexus cho từng nhánh tính năng
• chia sẻ kho lưu trữ cục bộ trên các nô lệ chuyên dụng
• sử dụng repository-server-plugin với các kho lưu trữ ngược dòng
• xây dựng tất cả trong một công việc với một kho lưu trữ riêng

Trên thực tế, giải pháp cuối cùng là hứa hẹn nhất. Tất cả các giải pháp khác đều thiếu theo cách này hay cách khác. Cùng với plugin job-dsl, bạn có thể dễ dàng thiết lập một nhánh tính năng mới. chỉ cần sao chép và dán script thú vị, điều chỉnh các nhánh và để công việc hạt giống tạo ra các công việc mới. Đảm bảo rằng công việc hạt giống loại bỏ các công việc không được quản lý. Sau đó, bạn có thể dễ dàng mở rộng quy mô với các nhánh tính năng trên các dự án maven khác nhau.

Nhưng như tom đã nói ở trên, sẽ tốt hơn nếu vượt qua sự cần thiết của các nhánh tính năng và dạy các nhà phát triển tích hợp một cách rõ ràng, nhưng đó là một quá trình dài hơn và kết quả không rõ ràng với nhiều phần hệ thống cũ mà bạn sẽ không chạm vào nữa.

2 xu của tôi