Chiến lược hợp nhất 1 năm phát triển trong Visual Studio

Tôi có một khách hàng khăng khăng rằng chúng tôi giữ cho sự phát triển mới của chúng tôi tách biệt với các chi nhánh chính trong toàn bộ năm 2016. Họ có 3-4 nhóm khác làm việc trên ứng dụng ở nhiều khả năng khác nhau. Nhiều thay đổi lớn đã được thực hiện (chuyển đổi cách thực hiện tiêm phụ thuộc, làm sạch mã bằng ReSharper, v.v.). Bây giờ tôi đã phải hợp nhất chính vào chi nhánh nhà phát triển mới của chúng tôi để chuẩn bị đẩy các thay đổi của chúng tôi lên chuỗi.

Trong lần kéo hợp nhất ban đầu của tôi, TFS đã báo cáo ~ 6500 tệp có độ phân giải xung đột. Một số trong số này sẽ dễ dàng, nhưng một số trong số chúng sẽ khó khăn hơn nhiều (cụ thể là một số javascript, bộ điều khiển api và các dịch vụ hỗ trợ các bộ điều khiển này).

Có một cách tiếp cận tôi có thể thực hiện sẽ làm cho điều này dễ dàng hơn cho tôi?

Để làm rõ, tôi đã bày tỏ nhiều mối quan tâm với phương pháp này nhiều lần trên đường đi. Khách hàng đã và nhận thức được những khó khăn với điều này. Vì họ chọn cách gọi ngắn gọn cho nhân viên QA (1 người kiểm tra cho 4 nhà phát triển, không kiểm tra tự động, kiểm tra hồi quy nhỏ), họ đã nhấn mạnh rằng chúng tôi giữ cho chi nhánh của chúng tôi cách ly với những thay đổi trong chi nhánh chính theo giả định rằng điều này sẽ làm giảm nhu cầu của chúng tôi người kiểm tra để biết về những thay đổi đang được thực hiện ở nơi khác.

Một trong những vấn đề lớn hơn ở đây là nâng cấp lên phiên bản góc cạnh và một số phần mềm bên thứ ba khác - thật không may, chúng tôi không nghĩ ra cách nào tốt để xây dựng giải pháp này cho đến khi tất cả các phần được đặt lại.

Sẽ có một cách đơn giản giúp tách sự phát triển mới của bạn khỏi nhánh chính mà không đưa bạn vào tình huống không may này: bất kỳ thay đổi nào từ thân cây nên được sáp nhập vào nhánh dev của bạn hàng ngày . (Có phải khách hàng của bạn thực sự rất thiển cận đến nỗi anh ta không thể lường trước được rằng chi nhánh của bạn cần được đưa trở lại vào dòng chính một ngày nào đó?)

Dù sao, cách tiếp cận tốt nhất là IMHO cố gắng làm lại những gì đáng lẽ phải xảy ra trong tay:

• xác định ngữ nghĩa của các thay đổi trên dòng chính cho ngày 1 sau khi chi nhánh được tạo. Áp dụng chúng cho cơ sở mã hiện tại của bạn cũng như bạn có thể. Nếu đó là một "thay đổi cục bộ", thì nó sẽ đơn giản, nếu đó là một "tái cấu trúc chéo" như đổi tên một lớp được sử dụng rộng rãi, hãy áp dụng nó theo cách tương đương về mặt ngữ nghĩa với cơ sở mã hiện tại của bạn. Hy vọng trong năm đó, không có thay đổi xuyên suốt mâu thuẫn nào trong cơ sở mã được thực hiện trên nhánh "của bạn", nếu không điều này có thể trở thành một lời trêu ghẹo não thực sự
• kiểm tra kết quả (tôi đã đề cập đến việc bạn cần một bộ kiểm tra tốt cho nhiệm vụ này chưa)? Sửa tất cả các lỗi được tiết lộ bởi bài kiểm tra
• Bây giờ lặp lại quy trình này cho các thay đổi trên dòng chính cho ngày 2, rồi ngày 3, v.v.

Điều này có thể hoạt động khi các đội tuân thủ nghiêm ngặt các quy tắc kiểm soát phiên bản cổ điển ("chỉ cam kết có thể biên dịch, kiểm tra trạng thái" và "kiểm tra sớm và thường xuyên").

Sau 365 lần lặp lại (hoặc 250, nếu bạn may mắn và bạn có thể gói công việc cho các thay đổi vào cuối tuần), bạn sẽ gần như hoàn thành (gần như vì bạn cần thêm số lượng thay đổi sẽ xảy ra cho dòng chính trong giai đoạn tích hợp ). Bước cuối cùng sẽ là hợp nhất nhánh dev được cập nhật vào thân cây một lần nữa (vì vậy bạn không mất lịch sử của thân cây). Điều này sẽ dễ dàng, bởi vì về mặt kỹ thuật, nó chỉ là một sự thay thế của các tập tin bị ảnh hưởng.

Và vâng, tôi nghiêm túc, có lẽ không có lối tắt nào cho việc này. Nó có thể chỉ ra rằng "các phần hàng ngày" đôi khi có thể quá nhỏ, nhưng tôi không mong đợi điều này, tôi đoán có nhiều khả năng các phần hàng ngày có thể trở nên quá lớn. Tôi hy vọng khách hàng của bạn trả tiền cho bạn thực sự tốt cho việc này, và điều này rất tốn kém cho anh ta mà anh ta sẽ học được từ thất bại của mình.

Tôi nên thêm rằng bạn cũng có thể thử điều này với các mặt được chuyển đổi - tái hòa nhập các thay đổi từ chi nhánh của bạn thành các phần nhỏ đến dòng chính. Điều này có thể đơn giản hơn khi trên nhánh dev của bạn có ít thay đổi hơn so với trên thân cây hoặc hầu hết các thay đổi xảy ra trong các tệp nguồn mới hiện không phải là một phần của thân cây. Người ta có thể xem đây là "chuyển" một tính năng từ một sản phẩm A (nhánh dev) sang một sản phẩm B hơi khác (trạng thái hiện tại của thân cây). Nhưng nếu phần lớn các phép tái cấu trúc chéo được thực hiện trên dòng chính và chúng ảnh hưởng đến mã mới của bạn (6500 va chạm hợp nhất dường như là một bằng chứng cho điều này), thì có thể dễ dàng hơn theo cách tôi mô tả trước.

Ở giai đoạn hợp nhất tôi sẽ nói rằng việc hợp nhất tự động chỉ có thể làm phức tạp quá trình. Tôi đã gặp vấn đề tương tự với các chi nhánh đã chuyển hướng trong hơn một năm và phương pháp hiệu quả nhất tôi có là làm như sau:

• Lấy một bản sao của trạng thái không trộn lẫn ban đầu
• Khác biệt giữa không trộn lẫn và mới nhất
• Phá vỡ mọi yếu tố phổ biến
  • Ví dụ: thực hiện tất cả các thay đổi tên hàm, sau đó thay đổi tham số, v.v.
  • Bỏ qua khoảng trắng trên diff nếu các tiêu chuẩn đã thay đổi, nếu không bạn sẽ lãng phí rất nhiều thời gian để đếm không gian
• Tập trung vào chức năng cốt lõi trước

Cuối cùng, cảnh báo trình biên dịch và các khác biệt sẽ là những người bạn tốt nhất của bạn, tiếp tục sử dụng khác biệt không được trộn lẫn để xem chính xác những gì khác biệt và cứ tiếp tục. Có thể có nhiều công cụ khác nhau mà bạn có thể sử dụng để trợ giúp, nhưng điều đó sẽ tùy thuộc vào bạn để tìm ra công cụ nào là tốt nhất.

Chìa khóa là tiếp tục đi.

Chỉnh sửa:

Một lời cảnh báo, cách tiếp cận này sẽ có nghĩa là lịch sử kiểm soát phiên bản sẽ trở nên 'bị hỏng', vì bạn sẽ mất bằng chứng về sự hợp nhất giữa các chi nhánh, cũng như lịch sử của chi nhánh không được hợp nhất.

Cảm ơn các bình luận từ 'Jack Aidley' và '17 of 26 '

Vài năm trước, chúng tôi đã có một khách hàng có cùng yêu cầu giữ các chi nhánh riêng biệt. Vì vậy, chúng tôi đã làm.

Chúng tôi không bao giờ sáp nhập chi nhánh của họ trở lại. Họ đã có phiên bản độc đáo của riêng mình. Chúng tôi đã tính phí thêm cho các thay đổi vì về cơ bản chúng tôi có hai thân chính thay vì 1 thân chính và nhánh.

Chúng tôi đã cố gắng hợp nhất trở lại thân cây nhưng sau 2 tuần, chúng tôi quyết định từ bỏ nỗ lực đó vì nó đã đốt cháy hàng giờ không có lợi ích hữu hình.

Vì vậy, đừng hợp nhất nó lại. Tiếp tục hợp nhất các bản sửa lỗi quan trọng cho chi nhánh khách hàng đó khi cần thiết và bất kỳ cải tiến nào cũng sẽ được tính một lần cho khách hàng đó.

Nó sẽ không vui, nhưng nó sẽ đau đến mức nào tùy thuộc vào bản chất của những thay đổi và mức độ cô lập của chúng.

Tôi đề nghị bạn cố gắng hội tụ các nhánh thông qua tái cấu trúc càng nhiều càng tốt trước khi bạn thực hiện hợp nhất thực tế.

Công cụ hợp nhất là loại ngu ngốc vì nó chỉ nhìn vào sự khác biệt về văn bản và không hiểu mã theo bất kỳ cách nào. Nếu nhánh chính đã thay đổi tên của một lớp được sử dụng trong toàn bộ ứng dụng và nhánh tính năng sử dụng tên cũ trong một số mã mới, thì công cụ hợp nhất sẽ không hiểu rằng tên lớp cũng nên được thay đổi trong mã mới. Nhưng nếu bạn thực hiện tái cấu trúc trong nhánh B để đổi tên lớp như trong nhánh A, nó sẽ hoạt động theo cả mã cũ và mã mới và việc hợp nhất sẽ diễn ra suôn sẻ.

Thứ hai, bạn nên kiểm tra mức độ cục bộ của những thay đổi trong nhánh phát triển. Nếu các thay đổi trong nhánh tính năng được bản địa hóa ở một số khu vực, bạn không phải hội tụ mã không bị ảnh hưởng, bạn chỉ có thể sao chép và ghi đè từ nhánh chính.

Trong các lĩnh vực mã đã có những thay đổi không nhỏ trên cả hai nhánh, bạn phải kiểm tra cẩn thận mã và quyết định cách viết lại.