Thực hành tốt nhất với mã nguồn phân nhánh và vòng đời ứng dụng

Chúng tôi là một cửa hàng ISV nhỏ và chúng tôi thường gửi một phiên bản mới của các sản phẩm của chúng tôi mỗi tháng. Chúng tôi sử dụng Subversion làm kho lưu trữ mã và Visual Studio 2010 làm IDE. Tôi biết rất nhiều người đang ủng hộ Mercurial và các hệ thống kiểm soát nguồn phân tán khác nhưng tại thời điểm này tôi không thấy làm thế nào chúng ta có thể hưởng lợi từ những điều này, nhưng tôi có thể sai.

Vấn đề chính của chúng tôi là làm thế nào để giữ cho các nhánh và thân chính đồng bộ.

Đây là cách chúng ta làm mọi thứ ngày hôm nay:

1. Phát hành phiên bản mới (tự động tạo thẻ trong Subversion)
2. Tiếp tục làm việc trên thân cây chính sẽ được phát hành vào tháng tới

Và chu kỳ lặp lại mỗi tháng và hoạt động hoàn hảo. Vấn đề phát sinh khi một bản phát hành dịch vụ khẩn cấp cần được phát hành. Chúng tôi không thể giải phóng nó từ thân cây chính (2) vì nó đang được phát triển mạnh và nó không đủ ổn định để được phát hành khẩn cấp.

Trong trường hợp như vậy, chúng tôi làm như sau:

1. Tạo một nhánh từ thẻ chúng tôi đã tạo ở bước (1)
2. Vá lỗi
3. Kiểm tra và phát hành
4. Đẩy thay đổi trở lại thân cây chính (nếu có)

Vấn đề lớn nhất của chúng tôi là hợp nhất hai (chi nhánh với chính). Trong hầu hết các trường hợp, chúng tôi không thể dựa vào việc hợp nhất tự động vì ví dụ:

• rất nhiều thay đổi đã được thực hiện cho thân cây chính
• hợp nhất các tệp phức tạp (như các tệp XML của Visual Studio, v.v.) không hoạt động tốt
• một nhà phát triển / nhóm khác đã thực hiện các thay đổi mà bạn không hiểu và bạn không thể hợp nhất nó

Vì vậy, những gì bạn nghĩ là thực hành tốt nhất để giữ cho hai phiên bản khác nhau (nhánh và chính) đồng bộ. Bạn làm nghề gì?

Tôi nghĩ rằng cách tiếp cận của bạn để phân nhánh và hợp nhất là ổn, nhưng nếu vấn đề chính là cơ sở mã khá không ổn định, đó là điều bạn cần tập trung và giảm thiểu.

Điều chính yếu để đảm bảo là cơ sở mã có sự phân tách tốt các mối quan tâm . Sự phụ thuộc giữa các thành phần khác nhau cần được cách ly và giảm bớt. Điều này sẽ giải quyết phần lớn các vấn đề của bạn. Ngoài ra thực hành sau đây như nguyên tắc trách nhiệm duy nhất sẽ giúp.

Nếu một sự thay đổi kiến ​​trúc lớn cần phải xảy ra, nó sẽ diễn ra trong nhánh riêng của nó, và sau đó được sáp nhập trở lại chính sau khi được kiểm tra đầy đủ và 'ổn định' (trong lý do). Điều này có thể đau đớn và thách thức nhưng nó cũng nên hiếm. Nếu bạn có thực hành kiểm tra tốt tại chỗ thì rủi ro được giảm thiểu.

Nó cũng có thể giúp thay đổi thành một hệ thống kiểm soát phiên bản phân tán. Điều này sẽ cung cấp cho bạn một thân cây ổn định, với các tính năng khác nhau được hợp nhất từ ​​các nhánh khác nhau khi chúng sẵn sàng. Bạn vẫn sẽ bị đau khi hợp nhất nếu mã quá phụ thuộc lẫn nhau, nhưng bạn sẽ có nhiều quyền kiểm soát hơn.

Nhìn vào điều này từ một góc độ khác, cũng xem xét tăng giao tiếp giữa các nhóm của bạn. Chạy các cuộc họp standup theo phong cách nhanh nhẹn thường xuyên. Xem xét nơi các thành viên trong nhóm ngồi và làm thế nào có thể giúp đỡ. Nếu một sự hợp nhất phức tạp cần diễn ra, nó có thể không phải là một điều tồi tệ như vậy - sử dụng một phương pháp lập trình cặp sẽ mang lại sự hiểu biết cho cả hai bên.

Tôi có xu hướng nhìn nó từ khá nhiều theo cách ngược lại:

• Trunk phải luôn là mã sẵn sàng sản xuất (sau lần phát hành đầu tiên của bạn, nghĩa là).
• Cần có một nhánh kiểu phát triển chạy song song với thân cây, nơi phát triển hàng tháng của bạn xảy ra. Mỗi tháng khi đến thời gian phát hành, điều này được hợp nhất vào thân cây, thử nghiệm và sau đó được phát hành.
• Hotfix sau đó có thể dễ dàng được thực hiện trong thân cây của bạn và đăng ký, và luôn được triển khai thành công. Sau đó tạo một bản vá từ hotfix và áp dụng nó cho nhánh phát triển của bạn.

Tất nhiên, quy trình công việc này phù hợp hơn nhiều với một thứ không phải là SVN, bởi vì việc phân nhánh và hợp nhất tốt là điều gì đó khá đau đớn trong SVN, bất kể quy trình công việc của bạn. Theo kinh nghiệm của tôi, việc hợp nhất trong SVN gần như luôn luôn phải được thực hiện thủ công, bởi vì nó không hoạt động và không có cách nào thực sự xung quanh nó.

Gần đây, tôi đã ủng hộ một triết lý "phân nhánh và hợp nhất" như là kết quả cuối cùng. Tôi nghĩ rằng một sự thật đáng tiếc rằng việc xử lý mã hợp nhất từ ​​các chi nhánh không phải là vấn đề kỹ thuật, nhưng đó là một nhiệm vụ khó nhận thức: Tôi nghĩ đơn giản là bộ não con người không theo dõi đủ chi tiết để làm cho nó dễ dàng. Hơn nữa, tôi vẫn chưa thấy phân nhánh và sáp nhập thực sự hoạt động trong thực tế. Khi mã được phân nhánh, kinh nghiệm cho tôi biết rằng không có gì ngoài rắc rối để hợp nhất lại.

Một cách tiếp cận phát hành kỷ luật trên chính hoạt động tốt.

Phân nhánh SVN không được thiết kế linh hoạt. Tôi muốn đề nghị vấn đề đầu tiên của bạn nằm ở SVN; di chuyển từ đó sẽ mở ra các tùy chọn mới.