Chọn chiến lược phân nhánh phù hợp để phát hành

Bắt đầu với một nhóm phát triển mới trong một dự án mới và chúng tôi phải xác định chiến lược Phân nhánh cho kho lưu trữ nguồn của chúng tôi ( ví dụ: Microsoft Team Foundation Server 2010 ). Chúng ta đã gặp phải một cuộc thảo luận về việc có hay không ...

Một . Có một nhánh Phát hành mà chúng tôi xây dựng sản xuất và sau đó Dán nhãn khi có thứ gì đó thực sự được phát hành

HOẶC LÀ

B . Có một nhánh Phát hành mới cho mỗi Bản phát hành mới vào sản xuất ( Ví dụ: Phiên bản 1, 2, 3, v.v ... )

Tùy chọn A có vẻ khá đơn giản nhưng chúng tôi không chắc chắn liệu điều này có dẫn đến các vấn đề về lâu dài hay không. Tùy chọn B có vẻ như nó chỉ tạo ra rất nhiều nhánh sống một lần, chỉ chồng chất theo thời gian.

Có ai có bất kỳ kinh nghiệm nào có thể giúp chúng tôi quyết định không? Cụ thể, tôi đang muốn nghe điểm đau ở đâu cho bất kỳ một lựa chọn nào. Vui lòng cung cấp trải nghiệm cụ thể liên quan đến TFS và / hoặc ngụ ý Quản lý phát hành.

Tùy chọn A. Chỉ cần sử dụng đường chính và gắn thẻ để phát hành

Ưu điểm:

• Bạn tránh hợp nhất địa ngục.
• Giữ nguyên tuyến chính khuyến khích một số thực tiễn tốt nhất như lập kế hoạch phát hành phù hợp, không giới thiệu nhiều WIP, sử dụng phân nhánh bằng cách trừu tượng hóa để xử lý công việc dài hạn ngoài băng tần và sử dụng hệ thống đóng mở và các tính năng có thể định cấu hình để xử lý công việc trong tiến trình có thể; hoặc có thể không; cần phải bị vô hiệu hóa ngay bây giờ hoặc trong tương lai để phát hành hoặc để tránh hoàn toàn quay lại.

Nhược điểm:

• Xử lý các công việc đang tiến hành trở thành một vấn đề và thêm vào khu vực tấn công bề mặt tiềm năng khi đến lúc phát hành. Tuy nhiên, nếu nhà phát triển của bạn bị kỷ luật thì các tính năng mới sẽ có thể được cấu hình và mô-đun và do đó dễ dàng bị vô hiệu hóa / kích hoạt hoặc không có WIP và tại mỗi điểm phát hành, tất cả công việc đều được hoàn thành hoặc chưa được bắt đầu (ví dụ Scrum).
• Thay đổi quy mô lớn / ngoài dải đòi hỏi phải suy nghĩ nhiều hơn trước để thực hiện (ví dụ: phân nhánh bằng cách trừu tượng hóa).

Cá nhân tôi thích cách tiếp cận này. Phạm vi bảo hiểm mã và kiểm tra đơn vị sẽ xác định mã không sẵn sàng để ra khỏi cửa và mọi người không nên làm việc với mã sẽ không được phát hành trong lần lặp hiện tại. Phân nhánh bằng cách trừu tượng hóa hoặc các cơ chế khác có thể được sử dụng để đối phó với những thay đổi dài hạn và đang hoạt động.

Khi bạn không làm điều này, bạn bắt đầu thấy mình phải đối phó với các vấn đề hợp nhất, mã cũ, các tính năng không bao giờ được phát hành, v.v.

Tùy chọn B. Chi nhánh bằng cách phát hành

Ưu điểm:

• Bạn có thể bắt đầu làm việc trên lần lặp tiếp theo trong khi lần lặp hiện tại kết thúc vòng kiểm tra chấp nhận của nó.
• Những thứ khác tôi chắc chắn.

Nhược điểm:

• Tấn nhánh.
• Vẫn cần phải gắn thẻ các chi nhánh tại các điểm phát hành.
• Vẫn cần phải xử lý WIP và hợp nhất WIP từ nhánh phát hành trước vào nhánh phát hành tiếp theo nếu nó không tạo ra nó và vẫn cần phải vô hiệu hóa hoặc kéo nó ra khỏi nhánh phát hành và chạy lại các thử nghiệm chấp nhận
• Các bản sửa lỗi nóng cần được áp dụng cho nhiều chi nhánh hơn (phát hành chi nhánh + hotfix + thẻ mới + hợp nhất hotfix vào chi nhánh vnext và có thể là vnextnext tùy thuộc vào vị trí của hotfix.)

Tôi không phải là một fan hâm mộ lớn của giải pháp này ^ _ ^.

Nói chung tôi sẽ khuyên bạn chỉ nên cố gắng bám vào tuyến chính. Nếu các nhà phát triển của bạn gặp khó khăn khi không viết WIP có thể dễ dàng bị đánh cắp khi nó bị cắt hoặc được kiểm tra sớm cho lần phát hành tiếp theo thì bạn có thể bắt đầu nói về việc gắn thẻ mã tại điểm cần hoàn thành mã và phân nhánh từ đó nếu cần thiết để giải quyết các lỗi và lỗi bị bỏ qua mà các bài kiểm tra đơn vị nhà phát triển của bạn không thể nắm bắt được.

Lý tưởng nhất mặc dù tôi nghĩ rằng bạn muốn đó là quá trình ngoại lệ, không phải là quy tắc.

Tùy chọn C. Tùy chọn tiền thưởng điên

Nếu bạn muốn nhận được sự ưa thích, bạn cũng có thể xem xét mô hình phân nhánh theo từng người dùng / mỗi tính năng. ( Một ý tưởng khủng khiếp trong TFS hoặc bất kỳ DVCS nào đồng thời cực kỳ tầm thường để thực hiện nếu sử dụng DVCS như git hoặc đồng bóng ).

Trước đây, tôi đã thực hiện các điều dưới đây cho một nhóm bảo trì sử dụng lao động trước đây làm việc với một cơ sở mã kế thừa không thể dễ dàng chuyển sang từ đồng đội từ svn. Rất nhiều công việc không cần thiết đã được tham gia để đáp ứng yêu cầu kinh doanh của một tuyến chính luôn luôn đáng tin cậy thay vì chỉ phối hợp phát hành tốt hơn nhưng. . .

1. Các tính năng được phát triển bởi các nhà phát triển trong nhóm phát triển chi nhánh của họ.
2. Khi một tính năng đã sẵn sàng để được đánh giá ngang hàng, các nhà phát triển sẽ kết hợp nó lại với nhau thành một sự hợp nhất duy nhất từ ​​nhánh Dev vào nhánh CR và bao gồm câu chuyện id / người dùng tính năng trong tiêu đề. * Được thực thi bởi hook pre-commit *
3. Sau khi vượt qua CR, một công cụ quản trị được sử dụng để Quảng bá tính năng vào nhánh QA. (Tôi đã viết một ứng dụng thiết bị đầu cuối nhỏ liệt kê các câu chuyện của người dùng có trong các giai đoạn chấp nhận khác nhau và cho phép nhà điều hành quảng bá hoặc hạ cấp nó giữa các giai đoạn chấp nhận đó)
4. QA chạy tự động hóa và kiểm tra khả năng sử dụng thủ công. Nếu tính năng này tốt, nó sẽ được đẩy vào nhánh phát hành (đường chính). Nếu tính năng bị từ chối, nó bị hạ cấp / hoàn nguyên khỏi nhánh QA cho đến khi các nhà phát triển có thể giải quyết các vấn đề được đưa ra trong quá trình thử nghiệm và thêm gửi một bản vá cho nhánh CR.
5. Nếu mã được hoàn nguyên từ nhánh QA và sửa lỗi được áp dụng, công cụ đầu cuối sẽ áp dụng lại các thay đổi cần thiết để đưa tính năng trở lại nhánh QA từ nhánh CR để QA có thể xem lại mã và quảng bá nó hoặc hạ cấp nó một lần nữa.
6. Tại bất kỳ thời điểm nào, nhánh phát hành phải ở trạng thái ổn định đáng tin cậy.
7. Sau khi phát hành Dev, QA và CR mới được phát hành từ tuyến chính.

Chúng tôi có các chi nhánh riêng cho mỗi bản phát hành mà chúng tôi đưa ra (phần 4 một năm). Nó rất thuận tiện khi bạn cần phải kéo một bản phát hành cụ thể.

Nếu bạn cần duy trì một vài bản phát hành cũ hơn, tôi không nghĩ rằng việc dán nhãn sẽ làm được. Với các nhánh phát hành cụ thể, bạn có thể áp dụng các bản sửa lỗi nóng cho từng nhánh riêng biệt (hoặc cho một lựa chọn của chúng) mà không phải lo lắng về bất kỳ bản phát hành nào khác.

Nó cũng làm cho việc so sánh các bản phát hành dễ dàng hơn nhiều khi bạn đang tìm kiếm khi một lỗi hoặc một tính năng được giới thiệu.

Đừng lo lắng về số lượng chi nhánh hoặc về thời gian họ đi mà không thay đổi. Hệ thống phiên bản của bạn là để cung cấp cho bạn quyền kiểm soát và cung cấp lịch sử phát triển dự án của bạn. Lịch sử có xu hướng không thay đổi ... Và đừng lo lắng về việc cvs của bạn không thể đối phó. Chúng tôi sử dụng Perforce, 9000+ tệp trong một nhánh phát triển, tối đa 50 nhánh phát triển cho (các) bản phát hành mà chúng tôi đang làm việc và như đã nói, một nhánh duy nhất cho mỗi bản phát hành mà chúng tôi xuất bản. Perforce thậm chí không thở mạnh hơn.

Nói tóm lại: làm cho cuộc sống của bạn như một nhà phát triển / bảo trì / sửa lỗi / thợ săn vấn đề dễ dàng hơn và đừng lo lắng về số lượng chi nhánh hoặc số lượng tệp. Bất kỳ cvs tự tôn sẽ đối phó.

Biên tập:

Chúng tôi không phải chịu bất kỳ sự nhầm lẫn nào về số lượng chi nhánh chúng tôi có. Lược đồ đặt tên của chúng tôi cho các nhánh phát hành và chính sách 1 nhánh 1 của chúng tôi cho các nhánh phát triển (hoặc công việc) có thể có liên quan đến điều đó.

Các nhánh phát hành được đặt tên cho bản phát hành mà họ nắm giữ, tức là: R2011SP1 cho Gói dịch vụ phát hành 2011 1. Các nhánh công việc của chúng tôi có tên kém thông minh hơn: sub01, sub02, sub03, v.v. "Sub" xuất phát từ thực tế là tất cả các nhánh công việc là nhánh phụ của ngành chấp nhận. Chi nhánh chấp nhận là một trong đó tất cả các vấn đề được thu thập đã sẵn sàng để được phát hành.

Chính sách chi nhánh 1 công việc 1 của chúng tôi, kết hợp với thực tế là hệ thống theo dõi vấn đề của chúng tôi đã được tùy chỉnh với trường "chi nhánh" đảm bảo rằng chúng tôi luôn biết vấn đề nào được phát triển ở chi nhánh nào. Khi một vấn đề được tích hợp vào nhánh chấp nhận, trường này được cập nhật. Điều này có nghĩa là chúng tôi luôn biết vấn đề nào đã sẵn sàng để phát hành (một khi thử nghiệm chấp nhận được thực hiện). Tương tự, chúng tôi cập nhật trường này khi một nhánh phát hành được tạo và theo cách này chúng tôi luôn có thể theo dõi trong đó phát hành một vấn đề được phát hành.

Đó là tất cả về bối cảnh: tần suất bạn phát hành và những gì trong một bản phát hành.

Đây là một chút nghiên cứu trường hợp mà tôi đã có với công việc cũ của mình, sử dụng phương pháp B (chúng tôi gọi nó là chi nhánh theo mục đích ).

Để đặt câu chuyện trong bối cảnh,

• Một bản phát hành bao gồm các tính năng mới trong phần mềm của chúng tôi: chế độ chơi trò chơi mới, chức năng mới, tùy chọn cấu hình mới.
• Chu kỳ phát hành khá dài: khách hàng của chúng tôi là các trường đại học sẽ gắn bó với một tính năng thường được đặt trong một năm.

Sự phát triển chính đã được thực hiện trong thân cây cho đến khi chúng tôi đạt đến trạng thái hoàn thành tính năng cho một bản phát hành nhất định. Tại thời điểm đó, chúng tôi sẽ tạo một chi nhánh, giả sử tên dự án-tháng một năm 2012 và thực hiện kiểm tra chất lượng và sửa lỗi trong chính chi nhánh đó. Khi chúng tôi đã sẵn sàng để phát hành công khai, chúng tôi sẽ gắn thẻ mã trong nhánh đó và phát hành.

Tuy nhiên, sự phát triển trên bản phát hành không kết thúc ở thẻ đó. Chắc chắn, chúng tôi đã có những khách hàng tìm thấy lỗi hoặc các vấn đề nhỏ với bản phát hành. Vì vậy, trong trường hợp đó, tất cả những gì chúng ta cần làm là quay trở lại nhánh đó, vá mã và tạo một phiên bản được gắn thẻ mới của nhánh janftime2012 sẽ được phát hành và hợp nhất các bản sửa lỗi trở lại thân cây.

Trong trường hợp của chúng tôi, cách tiếp cận này rất thuận lợi vì một số người dùng thích ở lại với các bản phát hành cũ hơn với một bộ tính năng hạn chế hoặc đơn giản vì chi phí triển khai trên cơ sở hạ tầng của họ một phiên bản hoàn toàn mới thay vì một hotfix gây ra một số vấn đề.

Vì vậy, những câu hỏi bạn phải tự hỏi mình là:

• Bao lâu thì tôi phát hành?
• Các bản phát hành của tôi sẽ tương thích ngược 100%?
• Khách hàng của tôi sẽ ổn với việc nâng cấp hoàn toàn để sửa lỗi chứ?

Nếu bạn phát hành thường xuyên, thì có lẽ không đáng để có các nhánh cho mỗi người trong số họ. Tuy nhiên, nếu chu kỳ phát hành của bạn khá dài như trường hợp sử dụng cũ của tôi và việc triển khai, khả năng tương thích ngược và khách hàng bám vào các bản phát hành cũ có thể gặp rủi ro, tùy chọn B chắc chắn sẽ giúp bạn đỡ đau hơn, sẽ giúp mọi thứ dễ dàng hơn rất nhiều khách hàng của bạn với chi phí tối thiểu để đối phó với sự lộn xộn chi nhánh.

Tôi thích tùy chọn A. Phát triển trên các bản phát hành thân và nhánh khi chúng ổn định. Điều này hạn chế đáng kể công việc trong việc tích hợp các bản sửa lỗi nóng được áp dụng cho bản phát hành sản xuất.

Tôi đã được ký hợp đồng để giúp một đội đã cố gắng tùy chọn B trở lại đúng hướng.

Một vài điều cần xem xét.

• Di chuyển hotfix chuyển tiếp thông qua tất cả các nhánh mã hoạt động. Điều này có thể được thực hiện bằng cách hợp nhất, vá lỗi và / hoặc tái phát triển. Chúng nên được quản lý đầy đủ để đảm bảo sửa lỗi được áp dụng cho tất cả các bản phát hành phù hợp, sau đó đến trung kế.
• Xem xét các nhánh tính năng để cho phép phát triển các tính năng tách biệt khỏi luồng mã chính. Đây là những lời khuyên cho những thay đổi thử nghiệm. Vui lòng từ bỏ các nhánh tính năng nếu tính năng này không hoạt động.
• Tag và theo dõi các điểm hợp nhất của bạn.
• Chi nhánh bản phát hành của bạn khi được yêu cầu. Tôi thấy điều này là bình thường khi bản phát hành đã sẵn sàng để phát hành bản dựng ứng viên. Trong một số trường hợp giới thiệu các thay đổi không tương thích với thân cây có thể buộc và nhánh sớm. Hãy xem xét một nhánh tính năng.

Tôi đã làm việc trong một số năm trên một hệ thống sử dụng một cái gì đó giữa hai sơ đồ mà bạn mô tả. Điều quan trọng là có một sơ đồ đánh số đa cấp đang được sử dụng. Cấp độ bên ngoài về cơ bản là phiên bản API và được quản lý trên các nhánh (với sự hợp nhất chéo phù hợp khi cần sửa lỗi trên nhiều nhánh) và cấp độ bên trong là bản phát hành chính xác được thực hiện, được quản lý bằng thẻ.

Đặc biệt, nếu chúng tôi biết khách hàng có phiên bản chính xác nào, chúng tôi biết chính xác mã nguồn được xây dựng từ đâu và có thể tạo một bản sao chính xác để chúng tôi có thể thấy chính xác những gì đang diễn ra. Điều này rất quan trọng để hỗ trợ! Tuy nhiên, cấp độ bên ngoài của các nhánh, các phiên bản API mà chúng tôi hiện đang phát hành, chúng phát triển theo thời gian (với thân phát triển chính nhận được phần lớn các tính năng mới). Ngoài ra, khi chúng tôi thực hiện một bản phát hành chính mới của API, chúng tôi sẽ tạo một nhánh mới để hỗ trợ từ đó (vì vậy thân cây luôn có thể được định hướng phát triển cốt lõi) và chúng tôi xem xét liệu chúng tôi có nên hỗ trợ lâu đời nhất hiện tại không chi nhánh.

Vì vậy, tôi đề nghị một cái gì đó thực sự là hỗn hợp của cả A và B ; cả hai đều có những khía cạnh tốt, nhưng bản thân nó không hoàn chỉnh. Sử dụng tốt nhất của cả hai thế giới.

Trước đây, tôi đã sử dụng TFS để triển khai tùy chọn (B) một cách hiệu quả.

Phân nhánh / hợp nhất là một công cụ tuyệt vời khi nó được thực hiện thành từng phần nhỏ. Khó khăn không nằm ở việc tạo ra một nhánh (điều đó thật dễ dàng), cũng không phải đẩy công việc đáng giá trong một tuần lên cây (điều đó cũng dễ dàng) ... đó là việc hệ thống CI phía sau kiểm soát nguồn của bạn tự động hoạt động bạn.

Bởi vì việc phân nhánh là không cần thiết nếu hệ thống không tự động xây dựng và chạy thử nghiệm cho chi nhánh của bạn.

Chúng tôi đã tùy chỉnh quy trình xây dựng mặc định của TFS để nhận ra các đường dẫn tương đối của bộ thay đổi và thiết lập một quy ước để tùy chỉnh có thể nhận ra một nhánh mới (trái ngược với đơn giản là thư mục con mới dưới một số gốc phát triển). Nó rất trơn tru, dễ phân nhánh, dễ giết một nhánh và chúng tôi đã nhận được phản hồi liên tục từ hệ thống của chúng tôi để biên dịch và kiểm tra.

Tôi thấy rất nhiều người tuyên bố rằng các chiến lược này không thể thực hiện được theo TFS như thế nào và tôi tin rằng đó là do thiếu sự quen thuộc với các khả năng của công cụ xây dựng dựa trên XAML. TFS không chỉ là kiểm soát nguồn, đó là toàn bộ giải pháp và nên được sử dụng như vậy.