Chiến lược phân nhánh Git cho mã chưa được phát hành dài


15

Tại nhóm của chúng tôi, ngoài các đơn vị công việc riêng lẻ (Câu chuyện), chúng tôi có các chủ đề công việc dài hơn (Epics). Nhiều câu chuyện làm nên một bản anh hùng ca.

Theo truyền thống, chúng tôi đã có các nhánh tính năng cho mỗi Câu chuyện và hợp nhất những nhánh đó thành chủ khi chúng vượt qua QA. Tuy nhiên, chúng tôi muốn bắt đầu giữ lại việc phát hành các câu chuyện đã hoàn thành trong một Epic cho đến khi Epic được coi là "tính năng hoàn thành". Chúng tôi chỉ phát hành các tính năng này cho sản xuất khi toàn bộ Epic bị đóng. Hơn nữa, chúng tôi có một máy chủ xây dựng hàng đêm - chúng tôi muốn tất cả các Câu chuyện đã đóng (bao gồm cả những câu chuyện là một phần của Epics chưa hoàn chỉnh) sẽ được triển khai tự động đến máy chủ hàng đêm này.

Có bất kỳ đề xuất về cách quản lý repo của chúng tôi để đạt được điều này? Tôi đã xem xét giới thiệu "các nhánh sử thi", nơi chúng tôi sẽ hợp nhất các câu chuyện kín với nhánh sử thi liên quan thay vì trực tiếp làm chủ, nhưng mối quan tâm của tôi là:

  • Tôi lo lắng về những xung đột hợp nhất có thể phát sinh nếu các nhánh sử thi được giữ lâu
  • Các bản dựng hàng đêm sẽ yêu cầu hợp nhất tất cả các nhánh sử thi thành một nhánh "xây dựng hàng đêm". Một lần nữa, xung đột hợp nhất có thể phát sinh và điều này sẽ được thực hiện tự động

Câu trả lời:


23

Gợi ý đơn giản: đừng làm vậy.

Các chi nhánh git không dành cho các nhánh mã dài hạn, như được thảo luận ở đâyhttps://blog.newrelic.com/2012/11/14/long-rucky-branches-considered-harmful/ . Các chi nhánh được đối xử tốt nhất như những thứ thoáng qua được sử dụng để tổ chức các cam kết của một nhà phát triển cá nhân ở cấp độ hàng ngày. Vì vậy, nếu họ có một tên tương ứng với một cái gì đó mà người quản lý dự án (nói gì đến người dùng cuối) có thể quan tâm đến việc bạn đang làm gì đó sai.

Thực hành được khuyến nghị là sử dụng tích hợp liên tục với các tính năng bật tắt hoặc trừu tượng hóa chi nhánh để đảm bảo rằng:

  • tất cả các mã được tích hợp mọi lúc (ít nhất là mỗi ngày, tốt nhất là thường xuyên hơn)
  • những gì được triển khai là dưới sự kiểm soát rõ ràng.

1
Tôi nghi ngờ đây có thể là một câu trả lời phổ biến! Mối quan tâm chính của tôi với điều này là chi phí luôn duy trì cả việc triển khai 'trực tiếp' và 'tiếp theo' và cũng yêu cầu nhà phát triển làm việc trên một tính năng biết trước để xây dựng các thay đổi như các tính năng song song mới thay vì nâng cấp (/ thay thế) chức năng hiện có. Đoán nó kêu gọi một sự thay đổi tư duy lớn hơn trong nhóm.
Sitati

Bạn có thể sử dụng các nhánh để phát triển mã, không bao giờ sử dụng chúng để lưu trữ mã. Vì vậy, nếu bạn không chắc chắn nếu một nhiệm vụ là sửa chữa 30 phút hoặc làm lại 2 tuần, thì hãy bắt đầu trên một nhánh. Ngay khi bạn biết, hãy hợp nhất hoặc tái cấu trúc thành một bản tóm tắt / chuyển đổi sau đó hợp nhất.
soru

@Sitati: Tôi vừa hợp nhất một số mã trong một nhánh tính năng trong bốn tháng qua. Trong khi đó, develchúng tôi đã chuyển sang CMake từ Autotools, đã giới thiệu Travis CI, tái cấu trúc mã. Cuối cùng, việc hiểu tính năng mới dễ dàng hơn và áp dụng nó theo cách thủ công develhơn là cố gắng hợp nhất nó. Chúng tôi cũng có những sinh viên Thạc sĩ mới phát triển một tính năng mới trong một nhánh mà họ đã phân nhánh khi họ bắt đầu luận án. Sau một năm, họ đã đẩy nó và không có nỗ lực nào để đưa nó trở lại, do đó, việc hợp nhất ngày này qua ngày khác trở nên khó khăn hơn.
Martin Uting

2
Các bài đăng blog được liên kết bây giờ là 5 tuổi. Tôi ghét tính năng toggles. Có gì sai khi phân nhánh dài hạn, thường xuyên sáp nhập trở lại vào nhánh tính năng từ chính và thêm tích hợp liên tục vào nhánh tính năng dài hạn?
Jason Kelley

CI là tên của một quá trình, không phải là một công cụ. Nếu bạn có nhiều nhánh tính năng, thông thường chúng sẽ không được tích hợp liên tục với nhau. Có nghĩa là tìm ra vấn đề muộn hơn là sớm hơn.
soru

1

Tôi nghĩ rằng đây là một vấn đề khá phổ biến và tập trung vào việc chọn các tính năng để đưa vào một bản phát hành sau khi các tính năng đã được mã hóa thay vì trước đó.

ví dụ.

Tôi có các tính năng A, B và C cho v2 của sản phẩm của mình. B và C có liên quan với nhau, tôi không muốn giải phóng B trừ khi C cũng kết thúc.

Tôi có ba nhà phát triển làm việc cùng một lúc về các tính năng.

Tôi có một bộ trong ngày phát hành đá D

B kết thúc và sáp nhập, A kết thúc và sáp nhập. C bị trì hoãn ... tôi phải làm gì?!

Tôi không tin có một giải pháp kỹ thuật cho vấn đề này. Bạn muốn phát hành phiên bản chưa được kiểm tra của sản phẩm chỉ có tính năng A đi kèm. Trừ khi bạn hợp nhất và kiểm tra tất cả các kết hợp tính năng có thể, đây sẽ luôn là một khả năng.

Giải pháp là một con người hơn. Bạn đã bỏ lỡ ngày phát hành của bạn và phải đẩy nó trở lại.


1

Đây là một vấn đề khó khăn nhưng là một vấn đề mà nhiều người phải đối mặt. Tôi thích sử dụng thiết lập Gitflow làm điểm bắt đầu.

Phát triển -> Công cụ mới đang được thực hiện trên
Master -> Công cụ đã hoàn thành cần thử nghiệm Sản xuất -> Công cụ đã được xuất bản để sản xuất.

Tại các tính năng nhỏ (ngắn hơn) tôi tạo một nhánh từ phát triển thực hiện công việc ở đó sau đó sáp nhập nhánh trở lại phát triển.

Tại các tính năng chính (dài hạn) tôi tạo một nhánh từ sự phát triển, tạo các nhánh nhỏ hơn từ nhánh đó, sau đó hợp nhất trở lại nhánh đầu tiên. Khi tính năng chính hoàn thành rồi quay lại nhánh phát triển.

Theo các khoảng thời gian đều đặn (tùy thuộc vào dự án), tôi hợp nhất phát triển trở lại thành chủ và một chu kỳ thử nghiệm bắt đầu. Nếu bất kỳ sửa lỗi nào xuất hiện trong thử nghiệm, chúng được thực hiện trong nhánh chính (nhánh phụ sau đó hợp nhất vào). Và phát triển có thể tiếp tục trên nhánh chính trong quá trình thử nghiệm.

Bất cứ lúc nào chủ nên được sáp nhập vào phát triển, và phát triển nên được hợp nhất với bất kỳ nhánh phụ dài hạn nào của nó.

chủ nên luôn luôn (về lý thuyết) sẵn sàng cho sản xuất. Phát triển phải luôn luôn (về lý thuyết) phải sẵn sàng cho sản xuất. Lý do duy nhất có một sự khác biệt là nó cung cấp một bộ tính năng vững chắc cho người kiểm tra thử nghiệm.

Khi đã sẵn sàng, một cam kết chính được kiểm tra sẽ được hợp nhất vào sản xuất và triển khai trong sản xuất xảy ra từ chi nhánh đó. Các HOTFIX cần được thực hiện trong trường hợp khẩn cấp sau đó có thể diễn ra trên nhánh Sản xuất mà không phải hợp nhất trong tổng thể (có thể có nhiều thay đổi chưa được kiểm tra).

Cây bình thường của tôi trông giống như

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production  

Đó là quy tắc chung của tôi rằng không có thay đổi nào sẽ mất nhiều hơn sau vài giờ. Nếu có thì nó cần phải được thực hiện thành những thay đổi nhỏ hơn. Nếu đó là một tính năng rất lớn (như giao diện người dùng viết lại) thì điều đó sẽ diễn ra lâu dài để sự phát triển bình thường có thể tiếp tục cùng một lúc. Các nhánh LongTerm thường chỉ là các nhánh cục bộ trong khi Development, Master và Production là các nhánh từ xa. Bất kỳ chi nhánh cũng chỉ địa phương. Điều này giữ cho kho lưu trữ sạch sẽ cho người khác, mà không mất đi tính hữu dụng của git trên bộ tính năng dài hạn.

Tuy nhiên, tôi muốn lưu ý rằng sự tồn tại của một nhánh dài hạn là một điều hiếm. Thông thường, tất cả công việc của tôi đang trong quá trình phát triển. Chỉ khi tôi có một tính năng (bộ) sẽ mất nhiều thời gian thì tôi mới có thể làm việc trên các công cụ dev bình thường, tôi mới sử dụng nhánh LongTerm. Nếu đó chỉ là một tập hợp các thay đổi nên cùng nhau thì tôi chỉ không hợp nhất để làm chủ cho đến khi hoàn thành mọi việc.


"Tại các tính năng chính (dài hạn) tôi tạo một nhánh từ phát triển" - bạn không nên tạo các nhánh tính năng (phát triển) mới từ nhánh Sản xuất? Xem như nhánh sản xuất là mã sẵn sàng phát hành.
robotron

Không, sản xuất đã được phát hành, chủ đi trước sản xuất và phát triển là trước chủ. Một tính năng mới như thêm thuế vào tổng đơn hàng là vô nghĩa nếu bạn không làm việc với mã đã có đơn hàng.
coteyr

Nhưng nếu bạn phân nhánh từ dev và sau này hợp nhất trở lại thì nhánh đó (và do đó là master và Production sau này), sau đó kết hợp tất cả các thay đổi dev được thực hiện bởi những người khác cho đến khi phân nhánh? Một số thay đổi có thể không có sự chấp thuận của QA. Có lẽ đã nói về các cách tiếp cận khác nhau để phát hành quản lý.
robotron

Có nó sẽ, đó là điểm. QA kiểm tra trên một SHA cụ thể trong tổng thể, nhưng bạn không thể giữ được điều đó.
coteyr

"Kiểm tra QA trên một SHA cụ thể trong tổng thể" -> QA kiểm tra từng tính năng mới dưới dạng độc lập? Hãy để tôi điều hành cho bạn một kịch bản điển hình mà nhóm của tôi phải đối mặt: giả sử bạn có 2 dự án chạy dài trên cùng một cơ sở mã: Dự án A nằm trong QA trong tháng qua và sẽ là QA cho một tháng nữa. Dự án B đã được phát triển trong 6 tháng qua và hiện đã sẵn sàng cho QA. Dự án A được sáp nhập vào chủ và chắc chắn không sẵn sàng sản xuất do nhiều lỗi quy tắc kinh doanh tinh tế. Làm thế nào để chúng tôi xử lý dự án B? A và B phải được kiểm tra cùng nhau để kiểm tra các tương tác (B sẽ không gây ra xung đột trong quá trình hợp nhất).
robotron
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.