Các mô hình tích hợp liên tục và DVCS

Chúng tôi hiện đang sử dụng Subversion và TeamCity, chúng tôi sẽ chuyển sang sử dụng Mercurial (cụ thể là Kiln với tư cách là người dùng FogBugz).

Rõ ràng điều này sẽ dẫn đến những thay đổi - hy vọng là những cải tiến - trong mô hình phát triển của chúng tôi (cả hai chúng tôi!) Nhưng một vấn đề tôi gặp phải là làm thế nào để cấu trúc mọi thứ để chúng tôi vẫn tận hưởng lợi ích của việc tích hợp liên tục / máy chủ CI của chúng tôi ( rằng có và sẽ vẫn là lợi ích được đưa ra, thảo luận về những điều nằm ngoài phạm vi của câu hỏi này ).

Với SVN, chúng tôi cam kết số lượng kho lưu trữ trung tâm hạn chế - hiệu quả là một kho cho mỗi dự án (ít nhiều một Giải pháp Visual Studio) để dễ dàng kích hoạt bản dựng và đảm bảo rằng tất cả các tệp đã được cam kết và không có tệp nào được cam kết phụ thuộc đi lạc, v.v. Nhưng nếu chúng ta sẽ tận dụng lợi thế của sự đồng bóng, chúng ta sẽ muốn có nhiều trường hợp lưu trữ hơn - nơi mà tôi mong đợi các thay đổi thường chảy theo một repo "sống" dứt khoát. Vấn đề tôi đang đấu tranh là việc repo trực tiếp đối với tôi dường như quá "muộn" để kích hoạt CI của tôi xây dựng OTOH một CI xây dựng cho mỗi dự án cho mỗi nhà phát triển có thể là quá mức (và gây ra các vấn đề khác).

Tôi đang câu cá một chút nhưng đó là bởi vì một trong những điều mà một repo lật đổ trung tâm mang lại cho một người (tôi, với thiết lập của chúng tôi!) Là rất rõ ràng về những gì sẽ xây dựng khi nào.

nb Tôi không hỏi về các cơ chế của việc sử dụng đồng bóng với tích hợp liên tục - Tôi có một điều trị cho một dự án cá nhân, các mô hình và cấu trúc của nó và quy trình thực hành / công việc mà tôi đang cố gắng thực hiện.

Đầu tiên, có nhiều bản dựng cho mỗi dự án trong TeamCity thực sự là hướng đi. Bản chất của nền tảng làm cho nó thực sự dễ dàng - nút sao chép là có lý do.

Trong mọi trường hợp, khi chúng tôi ở SVN, chúng tôi thường chạy 2 bản dựng cho mỗi dự án - một bản chỉ vào đường phát triển chính (trong trường hợp của chúng tôi là thân cây) và một bản chỉ vào nhánh phát hành của chúng tôi. Chúng tôi đã thực hiện thiết lập xây dựng này cho HG trong khi theo mô hình phân nhánh tương tự như mô hình này . Chỉ có thách thức thực sự là tìm kiếm một funk schwea mới về số bản dựng mà chúng ta không còn có thể sử dụng số sửa đổi SVN hiện tại.

Chúng tôi cố gắng và khuyến khích mọi người thúc đẩy tương đối thường xuyên, đặc biệt là khi có rất nhiều công việc đang diễn ra cùng một lúc và chúng tôi muốn chu kỳ phản hồi nhanh hơn. Chỉ vì đó là DCVS không có nghĩa là bạn chỉ phải đẩy một lần một ngày hoặc một cái gì đó.

Chúng tôi đã sử dụng Kiln khoảng một năm nay và đã thử một vài thứ khác nhau. Trường hợp chúng tôi đã kết thúc là sử dụng các nhánh được đặt tên (trái ngược với các bản sao nhánh) với chiến lược phân nhánh sau:

• phát triển mặc định "hoàn thành"
• tính năng theo dõi các công việc hiện đang được tiến hành
• phát hành chi nhánh theo dõi điểm mà chúng tôi phát hành từ mặc định

Vì vậy, công việc bắt đầu bằng cách tạo một nhánh tính năng từ mẹo mặc định hiện tại . Khi nhánh tính năng được thực hiện *, nhánh được đóng và hợp nhất trở lại mặc định .

Tại một số điểm, chúng tôi quyết định rằng chúng tôi đã sẵn sàng để phát hành, vì vậy chúng tôi tạo một nhánh phát hành mới từ mẹo hiện tại theo mặc định . Điều này cho phép chúng tôi thực hiện các thay đổi đối với mã hiện đang được sản xuất bằng cách cam kết với nhánh phát hành trong khi vẫn cho phép phát triển tích cực trên các nhánh tính năng và mặc định .

Để tích hợp liên tục, chúng tôi làm hai việc:

• Tích hợp "luôn bật" theo dõi trạng thái mặc định
• Tích hợp mới cho mỗi nhánh phát hành

Công việc nhánh mặc định cho chúng ta biết rằng cây nguồn chính của chúng ta luôn ổn định - các công việc nhánh phát hành cho chúng ta biết rằng các nhánh đó ổn định và cung cấp cho chúng ta đầu ra xây dựng mà chúng ta cần để đưa một bản phát hành vào sản xuất.

_{* Định nghĩa của chúng tôi về "thực hiện" là tính năng được cập nhật với các kết hợp từ mặc định và đã được phê duyệt trong đánh giá mã.}

Nếu bạn chuyển sang DVCS, như Hg, bạn không chỉ nhận được "phần phân tán", bạn còn có được toàn bộ sức mạnh của việc phân nhánh và hợp nhất tốt.

Xem xét rằng bây giờ bạn sẽ có một trình theo dõi vấn đề tốt và SCM tốt ... tại sao không tạo chi nhánh cho mỗi nhiệm vụ?

Mẫu "nhánh trên mỗi nhiệm vụ" không phải là mới (kiểm tra sách của Berczuk) nhưng đây chắc chắn là thứ cần thử.

Tôi đã giải thích chi tiết ở đây và những ưu và nhược điểm của CI so với "được kiểm soát" ở đây .