Bạn có tiếp tục phát triển trong một chi nhánh hoặc trong thân cây? [đóng cửa]

Giả sử bạn đang phát triển một sản phẩm phần mềm có bản phát hành định kỳ. Các thực tiễn tốt nhất liên quan đến phân nhánh và sáp nhập là gì? Cắt các nhánh phát hành định kỳ ra công chúng (hoặc bất kỳ khách hàng nào của bạn) và sau đó tiếp tục phát triển trên thân cây, hoặc xem thân cây là phiên bản ổn định, gắn thẻ nó như một bản phát hành định kỳ và thực hiện công việc thử nghiệm của bạn trong các nhánh. Mọi người nghĩ gì về thân cây được coi là "vàng" hay được coi là "hộp cát"?

Tôi đã thử cả hai phương pháp với một ứng dụng thương mại lớn.

Câu trả lời cho phương pháp nào tốt hơn phụ thuộc nhiều vào tình huống chính xác của bạn, nhưng tôi sẽ viết những gì mà kinh nghiệm chung của tôi đã thể hiện cho đến nay.

Phương pháp tổng thể tốt hơn (theo kinh nghiệm của tôi): Thân cây phải luôn ổn định.

Dưới đây là một số hướng dẫn và lợi ích của phương pháp này:

• Mã hóa từng tác vụ (hoặc tập hợp các nhiệm vụ có liên quan) trong nhánh riêng của nó, sau đó bạn sẽ có sự linh hoạt khi bạn muốn hợp nhất các tác vụ này và thực hiện một bản phát hành.
• QA nên được thực hiện trên mỗi nhánh trước khi nó được hợp nhất vào thân cây.
• Bằng cách thực hiện QA trên từng nhánh riêng lẻ, bạn sẽ biết chính xác nguyên nhân gây ra lỗi dễ dàng hơn.
• Giải pháp này quy mô cho bất kỳ số lượng các nhà phát triển.
• Phương pháp này hoạt động kể từ khi phân nhánh là một hoạt động gần như ngay lập tức trong SVN.
• Gắn thẻ cho mỗi bản phát hành mà bạn thực hiện.
• Bạn có thể phát triển các tính năng mà bạn không có kế hoạch phát hành trong một thời gian và quyết định chính xác khi nào nên hợp nhất chúng.
• Đối với tất cả các công việc bạn làm, bạn có thể có lợi ích của việc cam kết mã của bạn. Nếu bạn chỉ làm việc ngoài thân cây, có thể bạn sẽ giữ mã của mình không được cam kết rất nhiều, và do đó không được bảo vệ và không có lịch sử tự động.

Nếu bạn cố gắng làm ngược lại và thực hiện tất cả sự phát triển của bạn trong thân cây, bạn sẽ gặp các vấn đề sau:

• Vấn đề xây dựng liên tục cho các bản dựng hàng ngày
• Mất năng suất khi một nhà phát triển gây ra sự cố cho tất cả những người khác trong dự án
• Chu kỳ phát hành dài hơn, bởi vì cuối cùng bạn cần có một phiên bản ổn định
• Bản phát hành kém ổn định

Đơn giản là bạn sẽ không có sự linh hoạt mà bạn cần nếu bạn cố gắng giữ một nhánh ổn định và thân cây như hộp cát phát triển. Lý do là bạn không thể chọn và chọn từ thân cây những gì bạn muốn đưa vào bản phát hành ổn định đó. Nó sẽ được trộn lẫn với nhau trong thân cây.

Một trường hợp cụ thể mà tôi muốn nói là thực hiện tất cả sự phát triển trong thân cây, là khi bạn đang bắt đầu một dự án mới. Có thể có các trường hợp khác quá tùy thuộc vào tình huống của bạn.

Bằng cách này, các hệ thống kiểm soát phiên bản phân tán cung cấp sự linh hoạt hơn nhiều và tôi khuyên bạn nên chuyển sang hg hoặc git.

Tôi đã làm việc với cả hai kỹ thuật và tôi sẽ nói rằng phát triển trên thân cây và phân nhánh các điểm ổn định vì phát hành là cách tốt nhất để đi.

Những người ở trên phản đối rằng bạn sẽ có:

• Vấn đề xây dựng liên tục cho các bản dựng hàng ngày
• Mất năng suất khi một nhà phát triển gây ra sự cố cho tất cả những người khác trong dự án

có lẽ đã không sử dụng các kỹ thuật tích hợp liên tục.

Đúng là nếu bạn không thực hiện một số bản dựng thử nghiệm trong ngày, hãy nói mỗi giờ một lần hoặc lâu hơn, sẽ để ngỏ cho những vấn đề này sẽ nhanh chóng bóp nghẹt tốc độ phát triển.

Thực hiện một số bản dựng thử nghiệm trong ngày nhanh chóng gấp các bản cập nhật cho cơ sở mã chính để người khác có thể sử dụng nó và cũng thông báo cho bạn trong ngày nếu ai đó đã phá vỡ bản dựng để họ có thể sửa nó trước khi về nhà.

Như đã chỉ ra, chỉ tìm hiểu về một bản dựng bị hỏng khi bản dựng hàng đêm để chạy các bài kiểm tra hồi quy thất bại là hoàn toàn điên rồ và sẽ nhanh chóng làm mọi thứ chậm lại.

Hãy đọc bài viết của Martin Fowler về Tích hợp liên tục . Chúng tôi đã triển khai hệ thống như vậy của riêng mình cho một dự án lớn (3.000kSLOC) trong khoảng 2.000 dòng Posix sh.

Tôi có xu hướng thực hiện phương pháp "phát hành chi nhánh". Thân cây dễ bay hơi. Khi thời gian phát hành đến gần, tôi sẽ tạo một nhánh phát hành, mà tôi sẽ đối xử thận trọng hơn. Khi điều đó cuối cùng đã hoàn thành, tôi sẽ gắn nhãn / gắn thẻ trạng thái của kho lưu trữ để tôi biết phiên bản phát hành "chính thức".

Tôi hiểu có nhiều cách khác để làm điều đó - đây chỉ là cách tôi đã làm trong quá khứ.

Cả hai.

Các thân cây được sử dụng cho phần lớn sự phát triển. Nhưng chúng tôi hy vọng rằng những nỗ lực tốt nhất sẽ được thực hiện để đảm bảo rằng bất kỳ đăng ký nào vào cốp xe sẽ không phá vỡ nó. (được xác minh một phần bởi hệ thống xây dựng và kiểm tra tự động)

Các bản phát hành được duy trì trong thư mục riêng của họ, chỉ có sửa lỗi được thực hiện trên chúng (và sau đó được hợp nhất vào thân cây).

Bất kỳ tính năng mới nào sẽ rời khỏi thân cây ở trạng thái không ổn định hoặc không hoạt động đều được thực hiện trong nhánh riêng của nó và sau đó được sáp nhập vào thân cây khi hoàn thành.

Tôi thích và sử dụng cách tiếp cận được mô tả bởi Henrik Kniberg trong Kiểm soát phiên bản cho nhiều nhóm nhanh nhẹn . Henrik đã làm rất tốt khi giải thích cách xử lý kiểm soát phiên bản trong môi trường nhanh nhẹn với nhiều nhóm (cũng làm việc cho một nhóm trong môi trường truyền thống) và không có lý do nào để diễn giải anh ta vì vậy tôi sẽ chỉ đăng "bảng cheat" (mà là tự giải thích) dưới đây:

Tôi thích nó bởi vì:

• Nó rất đơn giản: bạn có thể lấy nó từ hình ảnh.
• Nó hoạt động (và quy mô) tốt mà không có quá nhiều sự hợp nhất và rắc rối xung đột.
• Bạn có thể phát hành "phần mềm làm việc" bất cứ lúc nào (trên tinh thần nhanh nhẹn).

Và chỉ trong trường hợp nó không đủ rõ ràng: việc phát triển được thực hiện trong "nhánh công việc", thân cây được sử dụng cho mã DONE (có thể phát hành lại). Kiểm tra kiểm soát phiên bản cho nhiều nhóm Agile để biết tất cả các chi tiết.

Một tài liệu tham khảo tốt về quy trình phát triển giúp giữ thân cây ổn định và thực hiện tất cả các công việc trong các nhánh là Hệ thống phát triển chất lượng cuối cùng của Divmod . Tóm tắt nhanh:

• Tất cả các công việc được thực hiện phải có một vé liên quan đến nó
• Một chi nhánh mới được tạo cho mỗi vé trong đó công việc cho vé đó được thực hiện
• Các thay đổi từ chi nhánh đó không được sáp nhập trở lại vào đường trục chính mà không được xem xét bởi một thành viên dự án khác

Họ sử dụng SVN cho việc này, nhưng điều này có thể dễ dàng thực hiện với bất kỳ hệ thống kiểm soát phiên bản phân tán nào.

Tôi nghĩ cách tiếp cận thứ hai của bạn (ví dụ, gắn thẻ phát hành và thực hiện các công cụ thử nghiệm trong các nhánh, xem xét ổn định thân cây) là cách tiếp cận tốt nhất.

Cần phải rõ ràng rằng các nhánh thừa hưởng tất cả các lỗi của một hệ thống tại thời điểm nó được phân nhánh: nếu các bản sửa lỗi được áp dụng cho một thân cây, bạn sẽ phải đi từng cái một cho tất cả các nhánh nếu bạn duy trì các nhánh như một loại kết thúc chu kỳ phát hành. Nếu bạn đã có 20 bản phát hành và bạn phát hiện ra một lỗi quay trở lại như bản phát hành đầu tiên, bạn sẽ phải áp dụng lại bản sửa lỗi của mình 20 lần.

Các nhánh được coi là các hộp cát thực sự, mặc dù thân cây cũng sẽ phải đóng vai trò này: các thẻ sẽ cho biết mã có "vàng" tại thời điểm đó hay không, phù hợp để phát hành.

Chúng tôi phát triển trên thân cây trừ khi những thay đổi quá lớn, gây bất ổn hoặc chúng tôi sắp phát hành một trong những sản phẩm của mình, trong trường hợp đó chúng tôi tạo ra một chi nhánh tạm thời. Chúng tôi cũng tạo ra một chi nhánh vĩnh viễn cho mỗi bản phát hành sản phẩm riêng lẻ. Tôi thấy tài liệu của Microsoft về Hướng dẫn phân nhánh khá hữu ích. Hướng dẫn phân nhánh của Eric Sink cũng rất thú vị và chỉ ra rằng những gì hoạt động cho Microsoft có thể quá nặng đối với một số người còn lại trong chúng ta. Đó là trong trường hợp của chúng tôi, chúng tôi thực sự sử dụng phương pháp mà Eric nói rằng nhóm của anh ấy làm.

Nó phụ thuộc vào tình huống của bạn. Chúng tôi sử dụng Perforce và thường có một số dòng phát triển. Thân cây được coi là "vàng" và tất cả sự phát triển xảy ra trên các nhánh được sáp nhập trở lại tuyến chính khi chúng đủ ổn định để tích hợp. Điều này cho phép từ chối các tính năng không thực hiện cắt giảm và có thể cung cấp khả năng gia tăng vững chắc theo thời gian mà các dự án / tính năng độc lập có thể nhận được.

Có chi phí tích hợp cho việc hợp nhất và bắt kịp các tính năng mới được đưa vào trong thân cây, nhưng dù sao bạn cũng sẽ phải chịu nỗi đau này. Việc mọi người cùng phát triển trên thân cây có thể dẫn đến một tình huống miền tây hoang dã, trong khi việc phân nhánh cho phép bạn mở rộng quy mô và chọn những điểm mà bạn muốn uống thuốc tích hợp đắng. Chúng tôi hiện đang mở rộng tới hơn một trăm nhà phát triển trên một tá dự án, mỗi dự án có nhiều bản phát hành sử dụng cùng các thành phần cốt lõi và nó hoạt động khá tốt.

Cái hay của việc này là bạn có thể thực hiện điều này một cách đệ quy: một nhánh tính năng lớn có thể là thân cây riêng của nó với các nhánh khác xuất hiện nếu nó. Ngoài ra, bản phát hành cuối cùng có được một chi nhánh mới để cung cấp cho bạn một nơi để bảo trì ổn định.

Cố gắng quản lý bảo trì mã sản xuất hiện tại phù hợp với sự phát triển mới là vấn đề tốt nhất. Để giảm thiểu những vấn đề đó, mã phải phân nhánh thành một dây chuyền bảo trì sau khi các nỗ lực kiểm tra đã hoàn thành và mã đã sẵn sàng để giao hàng. Ngoài ra, tuyến chính phải phân nhánh để hỗ trợ ổn định phát hành, để chứa các nỗ lực phát triển thử nghiệm hoặc thực hiện bất kỳ nỗ lực phát triển nào có vòng đời trải dài trên nhiều bản phát hành.

Một nhánh không bảo trì chỉ nên được tạo khi có khả năng (hoặc chắc chắn) các va chạm giữa các mã sẽ khó quản lý theo bất kỳ cách nào khác. Nếu chi nhánh không giải quyết vấn đề hậu cần, nó sẽ tạo ra một vấn đề.

Phát triển phát hành bình thường xảy ra trong dòng chính. Các nhà phát triển kiểm tra vào và ra khỏi dòng chính cho công việc phát hành bình thường. Công việc phát triển cho các bản vá cho Mã sản xuất hiện tại phải nằm trong nhánh của bản phát hành đó và sau đó được hợp nhất với dòng chính sau khi bản vá đã vượt qua thử nghiệm và được triển khai. Làm việc trong các chi nhánh không bảo trì nên được phối hợp trên cơ sở từng trường hợp.

Nó phụ thuộc vào quy mô của nỗ lực phát triển của bạn. Nhiều nhóm làm việc song song sẽ không thể làm việc hiệu quả trên cùng một mã (thân cây). Nếu bạn chỉ có một nhóm nhỏ những người làm việc và mối quan tâm chính của bạn là cắt một chi nhánh để bạn có thể tiếp tục làm việc trong khi quay lại chi nhánh để thực hiện sửa lỗi cho mã sản xuất hiện tại sẽ hoạt động. Đây là một sử dụng tầm thường của phân nhánh và không quá nặng nề.

Nếu bạn có nhiều sự phát triển song song, bạn sẽ muốn có các chi nhánh cho mỗi nỗ lực nhưng điều đó cũng sẽ đòi hỏi nhiều kỷ luật hơn: Đảm bảo các chi nhánh của bạn được kiểm tra và sẵn sàng hợp nhất trở lại. Lập kế hoạch hợp nhất để hai nhóm không cố gắng hợp nhất cùng một lúc, v.v.

Một số chi nhánh đang được phát triển quá lâu đến nỗi bạn phải cho phép sáp nhập từ thân cây đến nhánh để giảm số lượng bất ngờ khi cuối cùng hợp nhất trở lại thân cây.

Bạn sẽ phải thử nghiệm nếu bạn có một nhóm lớn các nhà phát triển và cảm nhận về những gì hoạt động trong tình huống của bạn. Đây là một trang của Microsoft có thể hữu ích một chút: http://msdn.microsoft.com/en-us/l Library / aa730834 (VS.80) .aspx

Chúng tôi đang sử dụng trung kế để phát triển chính và chi nhánh để phát hành công việc bảo trì. Nó hoạt động tốt. Nhưng sau đó các nhánh chỉ nên được sử dụng để sửa lỗi, không có thay đổi lớn, đặc biệt là về phía cơ sở dữ liệu, chúng tôi có một quy tắc là chỉ có thể thay đổi lược đồ trên thân chính và không bao giờ trong nhánh.

Nếu bạn đang làm việc trong một chu kỳ phát hành, tính năng lớn, bạn sẽ được kết hôn với một chi nhánh. Mặt khác, chúng tôi làm việc trong thân cây và chi nhánh cho mỗi bản phát hành sản xuất tại thời điểm chúng tôi xây dựng.

Các bản dựng sản xuất trước đó được chuyển vào thời điểm đó thành old_production_ và bản phát hành prod hiện tại luôn chỉ là sản xuất. Tất cả các máy chủ xây dựng của chúng tôi đều biết về sản xuất là cách triển khai chi nhánh sản xuất và chúng tôi khởi động việc xây dựng đó bằng một bộ kích hoạt lực.

Chúng tôi theo phương pháp trunk = luồng phát triển hiện tại, nhánh = phát hành (s). Khi phát hành cho khách hàng, chúng tôi phân nhánh thân cây và chỉ cần giữ thân cây lăn về phía trước. Bạn sẽ cần đưa ra quyết định về số lượng bản phát hành mà bạn chuẩn bị hỗ trợ. Bạn càng hỗ trợ nhiều việc hợp nhất bạn sẽ thực hiện trên các bản sửa lỗi. Chúng tôi cố gắng và giữ khách hàng của chúng tôi không quá 2 bản phát hành phía sau thân cây. (Ví dụ: Dev = 1.3, các bản phát hành được hỗ trợ 1.2 và 1.1).

Các thân cây nói chung là dòng phát triển chính.

Các bản phát hành được phân nhánh và thường các công việc thử nghiệm hoặc chính được thực hiện trên các nhánh sau đó được hợp nhất trở lại thân cây khi nó sẵn sàng để được tích hợp với dòng phát triển chính.

Thân cây thường là nguồn phát triển chính của bạn. Nếu không, bạn sẽ mất rất nhiều thời gian để hợp nhất trong các tính năng mới. Tôi đã thấy nó làm theo cách khác và nó thường dẫn đến rất nhiều cơn đau đầu tích hợp vào phút cuối.

Chúng tôi dán nhãn cho các bản phát hành của mình để chúng tôi có thể nhanh chóng đáp ứng các tình huống khẩn cấp sản xuất mà không làm ảnh hưởng đến sự phát triển tích cực.

Đối với tôi, nó phụ thuộc vào phần mềm tôi đang sử dụng.

Theo CVS, tôi sẽ chỉ làm việc trong "thân cây" và không bao giờ gắn thẻ / chi nhánh, bởi vì thật khó để làm khác.

Trong SVN, tôi sẽ thực hiện công cụ "cạnh chảy máu" của mình trong thân cây, nhưng khi đến lúc thực hiện một cú đẩy máy chủ sẽ được gắn thẻ thích hợp.

Gần đây tôi chuyển sang git. Bây giờ tôi thấy rằng tôi không bao giờ làm việc trong thân cây. Thay vào đó, tôi sử dụng một nhánh hộp cát "new-featurename" và sau đó hợp nhất thành một nhánh "sản xuất hiện tại" cố định. Bây giờ tôi nghĩ về nó, tôi thực sự nên tạo các nhánh "phát hành VERSIONNUMBER" trước khi hợp nhất trở lại "sản xuất hiện tại" để tôi có thể quay lại các phiên bản ổn định cũ hơn ...

Nó thực sự phụ thuộc vào mức độ tổ chức / nhóm của bạn quản lý các phiên bản và SCM bạn sử dụng.

• Nếu những gì tiếp theo (trong phiên bản tiếp theo) có thể dễ dàng được lên kế hoạch, bạn nên phát triển trong thân cây. Quản lý chi nhánh mất nhiều thời gian và nguồn lực hơn. Nhưng nếu kế tiếp không thể được lên kế hoạch dễ dàng (xảy ra mọi lúc trong các tổ chức lớn hơn), bạn có thể sẽ kết thúc các cam kết hái anh đào (hàng trăm / ngàn) thay vì các chi nhánh (nghiêm trọng hoặc hàng chục).
• Với Git hoặc Mercurial, việc quản lý các nhánh dễ dàng hơn nhiều so với cvs và lật đổ. Tôi sẽ đi cho thân cây ổn định / chủ đề chi nhánh phương pháp. Đây là những gì nhóm git.git sử dụng. đọc: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• Với Subversion, lần đầu tiên tôi áp dụng phương thức phát triển trong thân cây. Có khá nhiều công việc khi đến ngày phát hành bởi vì mỗi lần tôi phải cam kết chọn anh đào (công ty của tôi không giỏi lập kế hoạch). Bây giờ tôi là một chuyên gia về Subversion và biết khá rõ về các nhánh mana trong Subversion, vì vậy tôi đang tiến tới phương pháp thân cây / chủ đề ổn định. Nó hoạt động tốt hơn nhiều so với trước đây. Bây giờ tôi đang thử cách thức hoạt động của nhóm git.git, mặc dù chúng tôi có thể sẽ gắn bó với Subversion.

Đây là thiết kế SVN mà tôi thích:

• nguồn gốc
  • phát triển
    • chi nhánh
      • tính năng1
      • tính năng2
      • ...
    • Thân cây
  • beta
    • thẻ
    • Thân cây
  • giải phóng
    • thẻ
    • Thân cây

Tất cả các công việc được thực hiện từ phát triển / thân cây, ngoại trừ các tính năng chính yêu cầu chi nhánh riêng của nó. Sau khi công việc được kiểm tra chống lại sự phát triển / thân cây, chúng tôi hợp nhất các vấn đề được thử nghiệm vào phiên bản beta / thân cây. Nếu cần thiết, mã được kiểm tra đối với máy chủ beta. Khi chúng tôi sẵn sàng tung ra một số thay đổi, chúng tôi chỉ cần hợp nhất các phiên bản phù hợp vào bản phát hành / trung kế và triển khai.

Các thẻ có thể được tạo trong nhánh beta hoặc nhánh phát hành để chúng tôi có thể theo dõi bản phát hành cụ thể cho cả bản beta và bản phát hành.

Thiết kế này cho phép rất linh hoạt. Nó cũng giúp chúng tôi dễ dàng để lại các bản sửa đổi trong phiên bản beta / thân trong khi hợp nhất các bản khác để phát hành / trung kế nếu một số bản sửa đổi không vượt qua các bản kiểm tra trong bản beta.

Phương pháp chúng tôi sử dụng là phương pháp Perforce, được thảo luận rất dài trong cuốn sách tuyệt vời của Laura Wingerd:

http://oreilly.com/catalog/9780596101855/index.html

Mặc dù cuốn sách là trung tâm lực lượng (Wingerd là người quản lý sản phẩm Perforce), các khái niệm có thể được áp dụng cho bất kỳ hoặc tất cả các VCS.

Cách tiếp cận lực lượng (và nền tảng) đã phục vụ chúng tôi rất tốt. Nó được sử dụng tại rất nhiều công ty (google, Intuit, và, tôi đã nghe nói, chính Microsoft Windows).

Cuốn sách rất đáng để đọc.

Đọc này: http://oreilly.com/catalog/prrealperforce/ch CHƯƠNG / ch07.pdf

Không có câu trả lời một kích cỡ phù hợp cho câu hỏi quy ước lật đổ IMHO.

Nó thực sự phụ thuộc vào sự năng động của dự án và công ty sử dụng nó. Trong một môi trường có nhịp độ rất nhanh, khi một bản phát hành có thể xảy ra thường xuyên như cứ sau vài ngày, nếu bạn cố gắng gắn thẻ tôn giáo và chi nhánh, bạn sẽ kết thúc với một kho lưu trữ không thể quản lý được. Trong một môi trường như vậy, cách tiếp cận khi cần thiết sẽ tạo ra một môi trường dễ bảo trì hơn nhiều.

Ngoài ra - theo kinh nghiệm của tôi, cực kỳ dễ dàng, từ quan điểm quản trị thuần túy, để chuyển đổi giữa các phương pháp svn khi bạn chọn.

Hai cách tiếp cận mà tôi biết để làm việc tốt nhất là chi nhánh khi cần và chi nhánh mỗi nhiệm vụ. Tất nhiên, đây là những thứ hoàn toàn trái ngược với nhau. Như tôi đã nói - đó là tất cả về động lực của dự án.

@Brian R. Bondy: Xin lưu ý rằng đây không phải là giải pháp một khi nhóm của bạn đạt được một số lượng ppl / nhiệm vụ nhất định được xử lý song song trong dự án.

Khi một bộ phận QA có liên quan đến qa, những nỗ lực cần thiết để cung cấp một cài đặt cho mỗi chi nhánh đang tiến hành đơn giản là quá cao. Suy nghĩ SOA / Khách hàng / Máy chủ / Dịch vụ web / Cơ sở dữ liệu tất cả đều phải được cung cấp cho mỗi chi nhánh .

Giải pháp này cũng thiếu giai đoạn hội nhập.