Cách tốt hơn để xử lý phân nhánh và hợp nhất?

Question

Chúng tôi chạy một cửa hàng phát triển web với ~ 20 nhà phát triển đang làm việc trên ~ 30 trang web khác nhau vào bất kỳ thời điểm nào và chúng tôi đang chìm trong một khoảng thời gian đáng kinh ngạc để quản lý kho lưu trữ lật đổ của chúng tôi - phải có cách tốt hơn.

Các trang web khách hàng của chúng tôi thường có 3 môi trường triển khai riêng biệt: phát triển (thân cây), dàn dựng (nhánh) và sản xuất (nhánh).

Tính năng mới được xem xét nội bộ khi phát triển, sau đó hợp nhất với dàn dựng để xem xét và phê duyệt của khách hàng và cuối cùng được hợp nhất vào sản xuất.

Luồng công việc hiện tại của chúng tôi: Mọi nhà phát triển đang làm việc trên một tính năng mới lớn cho khách hàng sẽ tạo chi nhánh từ thân cây, làm việc trên tính năng của họ, trong khi thường xuyên cập nhật từ thân cây và sau đó hợp nhất các thay đổi về thân cây (phát triển) để xem xét nội bộ. Các nhà phát triển làm việc trên những thay đổi nhỏ hoặc sửa chữa, sẽ làm cho họ trực tiếp trong thân cây.

Sau khi đăng xuất nội bộ, các thay đổi sau đó được hợp nhất để dàn dựng. Nếu các thay đổi cần được thực hiện, chúng sẽ thường được tạo thành trong thân cây và sau đó được hợp nhất để dàn dựng. Sau khi được phê duyệt, các thay đổi sẽ được hợp nhất với sản xuất và sau đó được triển khai.

Tính năng mới không được xem xét tuần tự trong nội bộ hoặc bởi khách hàng, và toàn bộ mọi thứ trở nên khá lộn xộn. Có vẻ như chúng tôi đang sử dụng các quy trình sai - phải có cách tốt hơn để làm điều này. Chúng tôi rất quan tâm đến việc học cách sử dụng kiểm soát phiên bản tốt hơn, nhưng chúng tôi thiếu kinh nghiệm để bắt đầu quá trình.

Thực tiễn tốt nhất cho các tình huống này là gì? Ngoài diễn đàn này, chúng tôi quan tâm đến việc tham gia một nhà tư vấn có kinh nghiệm, những người có thể giúp chúng tôi cải tiến các quy trình của mình.

Cảm ơn bạn!

Answer 1

Tôi nghĩ rằng branching by feature (hoặc theo nhóm) sẽ tốt hơn so với phân nhánh theo nhà phát triển. Tính năng này có thể được kiểm tra và xem trước trước khi hợp nhất thông qua Development (Trunk) và vào nhánh Staging.

Nhóm của tôi đã có cấu trúc "Chi nhánh theo Chất lượng/Môi trường" tương tự mà tôi đã dành một vài tháng để nghiên cứu cách chuyển đổi tốt nhất để các nhà phát triển làm việc cùng nhau và chúng tôi có thể giảm thuế hợp nhất. Tôi muốn đề nghị như sau:

• Phát triển (Trunk/Main/Root chi nhánh)
  • (FeatureName1 [Version]) - thay thế chi nhánh cho mỗi nhà phát triển.
  • Staging (nếu bạn đang giữ tất cả các phiên trong một chi nhánh duy nhất)
  • Sản
  • (ReleaseName) (MajorVersion) Staging - Sở thích của tôi để cô lập các phiên bản khác nhau ngay cả khi phát hành cùng một môi trường
  • (ReleaseName) (Version) Sản xuất

sửa Staging được thực hiện trực tiếp tại các chi nhánh Staging (hoặc chi nhánh con ngắn ngủi của Staging nếu QA và/hoặc có nguy cơ bị cô lập nhiệm vụ), sau đó sáp nhập sửa lại để phát triển (Trunk) như soo n như sửa chữa được chấp nhận. THẬN TRỌNG: Chú ý đến bất kỳ sự hợp nhất nào từ Phát triển trong khi đang tiến hành khắc phục theo giai đoạn.

Từ quan điểm QA Tôi rất thích xây dựng theo giai đoạn cuối cùng và thử nghiệm là các tệp nhị phân/tệp giống hệt nhau được phát hành cho sản xuất. Thay đổi duy nhất phải là các tệp cấu hình (với các cài đặt cấu hình khác nhau được kiểm tra trong kho lưu trữ). Điều này có nghĩa là tôi thường tạo dựng cuối cùng trong "Dàn dựng" và nhánh "Sản xuất" hoặc ReleaseVersion là một tệp lưu trữ chỉ đọc mà không ai xây dựng. (Nhãn hoặc thẻ có thể được sử dụng thay vì chi nhánh lưu giữ an toàn này nếu nói lable là không thay đổi ... không phải là trường hợp của TFS 2010 :-(.)

Xem sơ đồ mát mẻ trong Visual Studio TFS Branching and Merging Guidance Bài viết MSDN từ tháng 2 năm 2011. để mở rộng quy mô ra này thấy Branching for Scrum và Parallel Feature Teams working on multiple releases in development. Monthly releases to production.. Cả hai đi kèm với một số sơ đồ tuyệt vời mà áp dụng cho bất kỳ hệ thống kiểm soát phiên bản.

tôi cũng đề nghị xem xét các TFS Branching Guide và diễn đàn thảo luận trong cùng một vị trí này để biết thêm tốt mô hình và hướng dẫn. (Phương pháp phân nhánh phần lớn độc lập với công cụ có ngoại lệ khi tránh yếu điểm công cụ.)

Tôi thấy ít nhất một lỗ hổng cơ bản trong quá trình phân nhánh ban đầu:

Sau khi ký tắt, các thay đổi sau đó được hợp nhất để dàn dựng. Nếu các thay đổi cần được thực hiện, chúng sẽ thường được tạo thành trong thân cây và sau đó được hợp nhất để dàn dựng.

Nếu thay đổi về Dàn dựng được thực hiện trong Phát triển và sau đó được hợp nhất thành Dàn dựng lần nữa thì bạn vừa kế thừa tất cả các thay đổi khác được thực hiện cho Chi nhánh phát triển kể từ lần hợp nhất cuối cùng đến Dàn xếp. HOẶC nếu bạn chọn lựa thay đổi (để lại tất cả các thay đổi khác được sáp nhập sau). Các công cụ SCM đang xử lý tốt hơn tình huống này, nhưng việc hợp nhất lựa chọn cherry vẫn giới thiệu những rủi ro đáng kể.

FYI: Mô hình ban đầu được mô tả tương tự như "Chi nhánh theo chất lượng" như được mô tả bởi Jeff Levinson. Nó có thể làm việc, nhưng bạn phải xem xét cẩn thận cách quản lý phân nhánh hotfix/qfe và sáp nhập các thay đổi về Trunk.

Answer 2

Thay vì có các chi nhánh riêng biệt cho dàn dựng và sản xuất, bạn có thể muốn xem xét các phương pháp sau đây:

Mỗi nhà phát triển luôn làm việc bên ngoài thân và khi đó là thời gian để đưa nó vào dàn, bạn tạo một thẻ cho biết một bản chụp mã đi tới môi trường dàn dựng.

Nếu khách hàng của bạn chấp thuận, bạn có thể tiếp tục và đẩy cùng một thẻ vào sản xuất.

Nếu họ không chấp thuận (nói rằng, họ đã tìm thấy lỗi), thì bạn cứ tiếp tục làm việc và tạo một thẻ khác có sửa lỗi.

LƯU Ý: vì SVN không có khái niệm được thực thi về 'thẻ', 'thẻ' về cơ bản là chi nhánh mà bạn vẫn có thể nhập mã. Tuy nhiên, bạn không được thay đổi (nghĩa là, cam kết) thẻ mà bạn đã tạo ra khỏi thân cây.

Answer 3

Bạn có thể xem xét thay đổi thành Git thay vì Subversion. Git hỗ trợ loại mô hình phân nhánh này rất tốt và rất nhẹ. Phải mất một chút làm quen với, đặc biệt là nếu bạn đang chuyển từ Subversion, nhưng cuối cùng nó mua cho bạn rất nhiều.

Một gợi ý Git công việc cho một tính năng mới có thể là:

1. Tạo một thân cây nhánh.
2. Tính năng triển khai, bao gồm các lần lặp lại đánh giá nội bộ, trên chi nhánh tính năng.
3. Khi khách hàng đăng xuất khỏi tính năng mới, hãy hợp nhất chi nhánh vào cả thân cây và sản xuất và (tùy chọn) xóa chi nhánh.

Bạn không thực sự cần phải có nhánh nhánh cho luồng công việc này. Bạn cũng không cần phải giữ các nhánh của đối tượng địa lý khi chúng được hợp nhất - Git sẽ nhớ lịch sử thay đổi.

Mô hình này hỗ trợ phát triển tính năng không đồng bộ/out-of-order và xem xét khá tốt, bởi vì mỗi chi nhánh tính năng về cơ bản là độc lập.

Chi nhánh rất rẻ trong Git và việc hợp nhất thường khá nhỏ.

Answer 4

Bạn không chính xác nói nó lộn xộn như thế nào, nhưng tôi đoán đó là khi mọi người sáp nhập chi nhánh tính năng của họ trở lại thân cây. Tôi sẽ đề xuất điều này dưới dạng quy trình làm việc:

1. Mọi người làm việc để triển khai tiếp theo hoạt động trên thân cây và cam kết thường xuyên; chỉ các tính năng có nhiều hơn một chu kỳ hoặc có khả năng không được bao gồm trong lần phân phối tiếp theo nên được thực hiện trên một nhánh riêng biệt. Chúng tôi gọi những nhánh phát triển đó và chúng sẽ được hợp nhất vào đầu chu kỳ phát triển - chứ không phải ở cuối.

2. Khi bạn đã sẵn sàng chuyển sang giai đoạn, hãy tạo nhánh phát hành. Tiếp tục thân cây như bản phát hành tiếp theo, hợp nhất trong bất kỳ nhánh phát triển nào được nhắm mục tiêu vào bản phát hành tiếp theo. Tại thời điểm này, sửa lỗi có thể phải được hợp nhất từ ​​chi nhánh trở lại thân cây, nhưng chỉ sửa lỗi và phát triển tính năng không được thêm vào nhánh, vì vậy nó không quá tệ. Trong thực tế, để giảm sự hợp nhất không cần thiết, chúng tôi thường ngừng tạo chi nhánh phát hành cho đến khi chúng tôi thực sự sẵn sàng bắt đầu làm việc các tính năng mới.

3. Khi đến lúc chuyển mã vào sản xuất, chỉ cần gắn thẻ nhánh phát hành và tiếp tục sử dụng nó. Sử dụng chi nhánh này để duy trì phiên bản này của mã với các bản vá lỗi cho đến khi tất cả các trang web khách hàng của bạn đã thay thế chúng bằng phiên bản tiếp theo.

Mô hình này nơi bạn phát triển trên một nhánh và mỗi bản phát hành được lưu trên một nhánh duy nhất hoạt động rất tốt cho chúng tôi trong môi trường mà đôi khi chúng tôi muốn sửa lỗi.