Làm thế nào để chuyển từ một thực tế phân nhánh phức tạp sang một mô hình một nhánh?

Trong các tổ chức lớn, sử dụng phương pháp thác nước thường dẫn đến các cấu trúc phân nhánh rất phức tạp (hay còn gọi là nhánh spagetti ).

Những chiến lược phân nhánh nào có thể được sử dụng để chuyển từ thực tế phân nhánh phức tạp sang mô hình một nhánh như phát triển dựa trên thân cây?

Cập nhật:

Để làm rõ, câu hỏi là về chính quá trình di chuyển / chuyển đổi , không phải về các phương pháp trước và sau, khá rõ ràng.

Nó thực sự không thể là "tại EOB hôm nay chúng ta vẫn còn thác với hàng ngàn nhánh nhưng ngày mai điều thứ nhất chúng ta sẽ chuyển sang CI đơn nhánh dựa trên thân cây".

Bởi vì bạn đề cập đến thác nước, tôi hiểu rằng rất nhiều nhánh bạn đang ám chỉ là nhánh đặc trưng chứ không phải nhánh bảo trì.

Trong thiết lập này, tôi cũng cho rằng các nhánh này được tạo theo kế hoạch thác nước cố gắng giảm thiểu xung đột. Điều này ngụ ý rằng mục tiêu của sự phát triển là sản xuất một số sản phẩm riêng biệt. Khi sử dụng mô hình phát triển một nhánh, điều quan trọng là cũng phải làm việc trên một sản phẩm. Nếu một số sản phẩm được phát triển đồng thời trong một mô hình phát triển một nhánh, thì nó có hiệu quả với các phiên bản của các sản phẩm này, do đó chúng ta có thể có trong phiên bản a của kho lưu trữ một sản phẩm lành mạnh X và một sản phẩm lỗi Y , trong khi ở phiên bản b sản phẩm X có hồi quy và sửa lỗi Y , nhưng chúng tôi không có phiên bản có cả X vàY khỏe mạnh. Một tình huống như vậy sẽ buộc chúng ta coi X và Y như được phát triển trong các kho riêng biệt, đó là một gợi ý mà họ nên có.

Do đó, các bước đầu tiên sẽ thực hiện phân chia kho lưu trữ :

1. Sắp xếp kho lưu trữ sao cho dễ dàng chia nó thành nhiều kho nhỏ. Ví dụ, sắp xếp lại kho lưu trữ hiện tại để mỗi thư mục cấp cao nhất tương ứng với kho lưu trữ bạn muốn tạo trong tương lai. Làm như vậy, bạn có thể tiếp tục sử dụng kỷ luật spaghetti chi nhánh mà mọi người đều quen thuộc.

2. Khi hoàn thành bước 1, hãy tinh chỉnh kỷ luật spaghetti chi nhánh bằng cách yêu cầu bất kỳ nhánh nào chỉ có thể chạm vào các tệp trong một thư mục cấp cao nhất.

3. Khi mỗi nhánh tuân thủ bước 2, thực hiện phân tách. Các nhà phát triển có thể dễ dàng chuyển đổi các thay đổi đang chờ xử lý của họ để vá một kho lưu trữ duy nhất, chỉ bằng cách xóa cấp độ đầu tiên của đường dẫn.

Bây giờ việc phân chia đã được thực hiện, bạn có thể bắt đầu làm việc với chính ngành học.

4. Giới thiệu các kỹ thuật lập trình giúp phát triển các nhánh sống ngắn. Các nhánh được tồn tại trong thời gian ngắn là một khía cạnh quan trọng của tất cả các phương pháp một nhánh. Một trong những mục tiêu của họ là giảm thời gian dành cho việc hợp nhất và gỡ lỗi các nhánh tồn tại lâu dài. Một kỹ thuật phổ biến là giới thiệu các tính năng của cờ-cờ, trong đó một nhà máy của Cameron, sử dụng cờ cấu hình để tạo ra phiên bản lịch sử của một đối tượng hoặc phiên bản mới, được phát triển một phần của đối tượng đó.

5. Đến bây giờ, bạn có hàng trăm kho lưu trữ chỉ có một vài nhánh trong mỗi kho, và bạn có thể biến nút chúng tôi trên toàn cầu áp dụng nút kỷ luật phát triển dựa trên thân cây, mà không thấy ngọn núi spaghetti gốc bị sụp đổ trên thân cây.

Việc phân chia kho lưu trữ thực tế có thể là tùy chọn, nhưng sau đó bạn sẽ phải áp dụng các chính sách phân định rõ ràng phạm vi được phép của mỗi bản vá được gửi (để hạn chế rủi ro xung đột khi hợp nhất các thay đổi trong nhánh chính). Giảm chi phí liên kết với xung đột là một trong những mục tiêu của các phương pháp mô hình một nhánh, vì vậy tôi cho rằng điều này có liên quan trong ngữ cảnh của bạn.

Khi di chuyển từ thứ này sang thứ khác, chỉ có hai điều bạn cần xác định:

1. Mục tiêu của bạn là gì
2. Làm thế nào để đến đó (kế hoạch di chuyển)

Phần đầu tiên, đáng buồn thay, thường bị bỏ qua hoặc cách quá mơ hồ. Bạn không thể đơn giản nói rằng những gì bạn có là một mớ hỗn độn và bạn muốn tổ chức nó. Điều đó có nghĩa là gì? Tất cả mọi người sẽ có một cách giải thích khác nhau (hay còn gọi là: mỗi dev nghĩ rằng mình hay mình cách làm việc là tốt nhất).

Rất có thể, tất cả các chi nhánh bạn đang phục vụ hoặc đã phục vụ một mục đích. Nếu không có một quy trình mục tiêu được xác định rõ ràng, mọi người sẽ tiếp tục làm những gì phù hợp với họ theo cách nó phù hợp nhất với họ (và đúng như vậy).

Ví dụ: mục tiêu của bạn phải được xác định rõ ràng như Vincent Driessen định nghĩa "mô hình phân nhánh Git thành công" của anh ấy . Nếu bạn nhìn vào mô hình này, nó rất chính xác: Nó nói nơi mã ổn định nên được phát triển và nơi các tính năng không ổn định nên được phát triển. Nó cũng cho biết làm thế nào - và khi nào - để phân nhánh, cập nhật và hợp nhất trở lại. Bạn biết mỗi chi nhánh để làm gì và phải làm gì với chúng. Chúng tôi sử dụng một biến thể của những gì được đưa ra bởi Vincent và biến thể của chúng tôi được xác định trong wiki của chúng tôi.

Điểm quan trọng là để tất cả các nhóm hiểu và đồng ý về một mục tiêu. Có thể đáng để nhắc nhở mọi người rằng bạn không tìm kiếm mô hình phân nhánh yêu thích cá nhân của họ, nhưng một mô hình mà tất cả các thành viên trong nhóm có thể đồng ý và sử dụng dễ dàng.

Khi bạn có mục tiêu của mình, bạn sẽ có thể xây dựng kế hoạch di chuyển của mình. Kế hoạch đó có thể dài hoặc ngắn như bạn muốn. Tôi đã thấy mô hình phân nhánh như vậy áp đặt qua đêm; ở những nơi khác, nó đã được thực hiện trong hơn 2 hoặc 3 lần chạy nước rút. Nó không quan trọng với tôi, miễn là chúng tôi đang cải thiện.

Bạn có thể bắt đầu với các nhánh "lớn nhất" hoặc quan trọng hơn. Ví dụ: "từ giờ trở đi, chủ phải luôn ở trạng thái được triển khai trong prod và nhánh dev phải luôn biên dịch" (hoặc bất cứ quy tắc nào của bạn). Sau đó, thực thi các phiên bản (phát hành) chi nhánh. Sau đó, thực thi các nhánh tính năng. Sau đó, áp đặt mã đóng băng trên nhánh phiên bản, nếu nó có ý nghĩa.

DevOps là tất cả về giao tiếp, cởi mở và hiệu quả. Những khái niệm này phải được ghi nhớ và truyền đạt trong suốt quá trình.

Tôi sẽ đề nghị mời một số người bên ngoài nhóm phát triển tham gia cuộc họp quy trình với tư cách quan sát viên. Ops hoặc quản lý cấp trung có thể có một hoặc hai điều để nói về mô hình của bạn. Nhu cầu của các nhà phát triển nên được ưu tiên, nhưng nếu mô hình phân nhánh không thể phù hợp với cách quản lý mọi thứ, bạn nên biết ngay bây giờ và không phải trong một hoặc hai tháng nữa.

Nếu bạn có những đội thực sự lớn, hãy cố gắng bao gồm tất cả mọi người. Với các đội rất lớn, dù sao bạn cũng sẽ có hai hoặc ba cuộc họp. Vì vậy, mời các trưởng nhóm trong phòng, nhưng có sẵn một webcast và cho mọi người biết về nó. Nếu bất cứ ai có một đề nghị hoặc mối quan tâm, họ sẽ có thể nói điều đó với trưởng nhóm của họ và nếu nó hợp lệ, nó sẽ được giải quyết trong cuộc họp thứ hai hoặc thứ ba.

Thực sự rất đơn giản để chuyển đổi một kho lưu trữ hydra nhiều nhánh thành một mô hình phân nhánh duy nhất.

Đầu tiên, bạn muốn bắt đầu với các nhánh có ít sự khác biệt nhất giữa chính nó và chủ hoặc thân cây. Kiểm tra tuổi và sự liên quan của họ. Nếu chúng vẫn còn liên quan, hãy bắt đầu hợp nhất chúng lại với nhau và giải quyết xung đột. Nếu chúng không còn phù hợp, sau đó xóa chúng.

Tiếp tục quá trình này cho đến khi bạn quản lý để hợp nhất tất cả các chi nhánh của mình, giải quyết tất cả các xung đột và bạn chỉ còn một chi nhánh duy nhất.

Bạn có thể làm theo phác thảo đơn giản này để bắt đầu:

1. Tạo một bản sao của nhánh chính / thân cây của bạn và gọi nó temp_master
2. Tìm nhánh có độ phân kỳ lớn nhất từ ​​master / trunk.
3. Xác định xem chi nhánh cần được lưu giữ, lưu trữ hoặc xóa.
   1. Nếu cần phải giữ, tiếp tục bước 4.
   2. Nếu nó cần được xóa hoặc lưu trữ, hãy xóa và lưu trữ nó, sau đó quay lại bước 2.
4. Lặp lại bước 2 để tìm nhánh tiếp theo có độ phân kỳ ít nhất.
5. Hợp nhất hai nhánh được tìm thấy trong bước 2 và bước 3, giải quyết tất cả các xung đột.
6. Hợp nhất hai chi nhánh của bạn vào temp_masterchi nhánh của bạn .
7. Kiểm tra mã trong mã temp_master để xem liệu nó có biên dịch, xây dựng và chạy bất kỳ kiểm tra tự động nào khác mà bạn có về sự tỉnh táo không.
   1. Nếu bất kỳ thử nghiệm nào thất bại, hãy quay lại, tìm hiểu lý do và khắc phục chúng, và lặp lại quy trình.
   2. Nếu thử nghiệm vẫn thất bại, chọn hai nhánh khác nhau để làm việc.
8. Lặp lại các bước 2 - 7 cho đến khi bạn chỉ có hai nhánh, chủ / thân và temp_master.
9. Cuối cùng, hợp nhất temp_mastervào master / trunk và sống với mô hình một nhánh mới của bạn.

Đối với các tổ chức lớn có chu kỳ chạy nước rút 4 tuần điển hình, Git-Flow được ưu tiên tiếp cận vì Bạn nhận được lợi ích của Chi nhánh tính năng Chi nhánh sản xuất chính luôn có thể triển khai Ngoài ra, chi nhánh chính được giữ sạch khỏi các cam kết không mong muốn bằng cách tuân theo hai chu kỳ cam kết (từ tính năng đến Developvà Developchi nhánh đến Thầy).

Hơn nữa, sự phân nhánh cũng được xác định bởi tần suất phát hành sản xuất. Để triển khai thường xuyên để sản xuất tốt hơn, nên có một nhánh Tính năng hoặc mô hình Tập trung. Trong trường hợp này, chi phí quản lý chi nhánh được chuyển sang thử nghiệm mạnh mẽ trong môi trường thấp hơn để duy trì sự ổn định sản xuất.