Xin lỗi về bài viết dài này, nhưng tôi nghĩ rằng nó là giá trị nó.
Tôi mới bắt đầu với một cửa hàng .NET nhỏ hoạt động khá khác biệt so với những nơi khác mà tôi đã làm việc. Không giống như bất kỳ vị trí nào trước đây của tôi, phần mềm được viết ở đây được nhắm mục tiêu đến nhiều khách hàng và không phải mọi khách hàng đều nhận được bản phát hành phần mềm mới nhất cùng một lúc. Như vậy, không có "phiên bản sản xuất hiện tại." Khi một khách hàng nhận được bản cập nhật, họ cũng nhận được tất cả các tính năng được thêm vào phần mềm kể từ lần cập nhật cuối cùng của họ, có thể là một thời gian dài trước đây. Phần mềm có cấu hình cao và các tính năng có thể được bật và tắt: được gọi là "tính năng bật tắt". Các chu kỳ phát hành rất chặt chẽ ở đây, trên thực tế chúng không theo lịch trình: khi một tính năng hoàn tất, phần mềm được triển khai cho khách hàng có liên quan.
Nhóm chỉ mới năm ngoái đã chuyển từ Visual Source Safe sang Team Foundation Server. Vấn đề là họ vẫn sử dụng TFS như thể đó là VSS và thực thi các khóa Checkout trên một nhánh mã. Bất cứ khi nào sửa lỗi được đưa ra hiện trường (ngay cả đối với một khách hàng), họ chỉ cần xây dựng bất cứ thứ gì có trong TFS, kiểm tra lỗi đã được sửa và triển khai cho khách hàng! (Bản thân tôi đến từ một nền tảng phần mềm dược phẩm và thiết bị y tế, điều này là không thể tin được!). Kết quả là một nửa mã dev nướng được đưa vào sản xuất mà không được kiểm tra. Lỗi luôn rơi vào các bản dựng phát hành, nhưng thường thì một khách hàng mới có bản dựng sẽ không thấy các lỗi này nếu họ không sử dụng tính năng của lỗi. Giám đốc biết đây là một vấn đề vì công ty đang bắt đầu phát triển bất ngờ với một số khách hàng lớn đến trên tàu và những khách hàng nhỏ hơn.
Tôi đã được yêu cầu xem xét các tùy chọn kiểm soát nguồn để loại bỏ việc triển khai mã lỗi hoặc chưa hoàn thành nhưng không hy sinh bản chất có phần không đồng bộ của các bản phát hành nhóm. Tôi đã sử dụng VSS, TFS, SVN và Bazaar trong sự nghiệp của mình, nhưng TFS là nơi mà hầu hết kinh nghiệm của tôi đã có.
Trước đây, hầu hết các nhóm tôi đã làm việc với việc sử dụng giải pháp hai hoặc ba nhánh của Dev-Test-Prod, trong đó một tháng các nhà phát triển làm việc trực tiếp trong Dev và sau đó các thay đổi được hợp nhất với Test rồi Prod hoặc quảng bá "khi hoàn thành" thay vì trên một chu kỳ cố định. Các bản dựng tự động đã được sử dụng, sử dụng Cruise Control hoặc Team Build. Trong công việc trước đây của tôi, Bazaar đã được sử dụng ngồi trên SVN: các nhà phát triển làm việc trong các nhánh tính năng nhỏ của riêng họ sau đó đẩy các thay đổi của họ sang SVN (được gắn vào TeamCity). Điều này thật tuyệt khi dễ dàng tách biệt các thay đổi và chia sẻ chúng với các chi nhánh của người khác.
Với cả hai mô hình này, có một nhánh trung tâm và prod (và đôi khi là thử nghiệm) thông qua đó mã được đẩy (và các nhãn được sử dụng để đánh dấu các bản dựng trong prod từ đó phát hành ... và chúng được tạo thành các nhánh để sửa lỗi để phát hành và sáp nhập trở lại dev). Điều này không thực sự phù hợp với cách làm việc ở đây, tuy nhiên: không có thứ tự nào khi các tính năng khác nhau được phát hành, chúng sẽ được đẩy khi chúng hoàn thành.
Với yêu cầu này, cách tiếp cận "tích hợp liên tục" như tôi thấy nó bị phá vỡ. Để có được một tính năng mới với sự tích hợp liên tục, nó phải được đẩy qua dev-test-prod và điều đó sẽ nắm bắt bất kỳ công việc còn dang dở nào trong dev.
Tôi nghĩ rằng để khắc phục điều này, chúng ta nên đi xuống một mô hình phân nhánh nhiều tính năng với các nhánh KHÔNG-test-prod, thay vào đó, nguồn nên tồn tại dưới dạng một loạt các nhánh tính năng mà khi công việc phát triển hoàn tất bị khóa, kiểm tra, sửa chữa, khóa , thử nghiệm và sau đó phát hành. Các nhánh tính năng khác có thể lấy các thay đổi từ các nhánh khác khi chúng cần / muốn, vì vậy cuối cùng tất cả các thay đổi sẽ được hấp thụ vào mọi người. Điều này rất phù hợp với mô hình Bazaar thuần túy từ những gì tôi đã trải nghiệm ở công việc cuối cùng.
Linh hoạt như điều này nghe có vẻ kỳ quặc khi không có nhánh dev hoặc nhánh prod ở đâu đó và tôi lo lắng về việc các chi nhánh không bao giờ được tích hợp lại, hoặc những thay đổi nhỏ đã khiến không bao giờ bị kéo sang các chi nhánh và nhà phát triển khác phàn nàn về hợp nhất thảm họa ...
Suy nghĩ của mọi người về điều này là gì?
Câu hỏi cuối cùng thứ hai: Tôi hơi bối rối về định nghĩa chính xác của kiểm soát nguồn phân tán: một số người dường như cho rằng đó là về việc không có kho lưu trữ trung tâm như TFS hoặc SVN, một số người nói rằng nó bị ngắt kết nối (SVN bị ngắt kết nối 90% và TFS có chế độ ngoại tuyến hoàn hảo về chức năng) và những người khác nói rằng đó là về Phân nhánh tính năng và dễ dàng hợp nhất giữa các nhánh không có mối quan hệ cha-con (TFS cũng có sự hợp nhất vô căn cứ!). Có lẽ đây là một câu hỏi thứ hai!