Chi nhánh tái cấu trúc và phát triển đồng thời

Question

Giả sử bạn có một số chi nhánh bảo trì cho bản phát hành phần mềm hiện có của mình. Một số nhà phát triển đang thực hiện các thay đổi trực tiếp trong các chi nhánh bảo trì và hợp nhất định kỳ vào thân cây. Bây giờ đến một refactoring rộng rãi trong codeline thân cây, dự kiến ​​cho một phát hành lớn sắp tới. Nhưng điều này làm cho các nhánh bảo trì về cơ bản không tương thích với mã trong thân cây, vì chúng có thể phụ thuộc vào mã không tồn tại nữa, ví dụ.

Bạn xử lý tình huống này như thế nào trong thực tế?

Answer 1

Tôi sẽ xem xét trách nhiệm của nhà phát triển bảo trì chi nhánh để hợp nhất thay đổi thích hợp vào trạng thái hiện tại của thân cây. Có một số khả năng:

1. Mã trong thân cây không thay đổi và bản vá được áp dụng mà không xung đột.
2. Mã trong thân cây đã thay đổi và bản vá được áp dụng, nhưng cần phải hợp nhất thủ công.
3. Mã trong thân cây đã hoàn toàn thay đổi và không thể áp dụng bản vá. Nhà phát triển phải đánh giá liệu có lỗi tương tự tồn tại trong thân cây và áp dụng sửa lỗi tương đương nếu cần.

Trường hợp 1 và 2 là đường dẫn phát triển bảo trì thông thường. Trường hợp 3 là trường hợp bạn đang xem xét, trong đó mã trunk không thể chấp nhận bản vá bảo trì dưới bất kỳ hình thức nào. Nếu nhà phát triển không thể tự xác định liệu cùng một vấn đề có thể tồn tại trong thân cây không, thì anh ta nên nhập một vấn đề vào hệ thống theo dõi vấn đề. Vấn đề này sẽ chỉ đạo các nhà phát triển thân cây để xem xét lý do cho các bản vá trong chi nhánh bảo trì và cho dù cùng một lỗi có thể vẫn còn tồn tại. Nhập một vấn đề mới cho một lỗi có thể trong thân cây phải là phương sách cuối cùng cho nhà phát triển bảo trì.

Một lợi ích của việc các nhà phát triển bảo trì cố gắng áp dụng các bản vá cho thân được cập nhật là tăng sự quen thuộc của họ với cơ sở mã mới. Cuối cùng, họ sẽ hết công việc bảo trì và sẽ cần phải làm việc với thân cây mới. Có ít nhất một mức độ quen thuộc cơ bản sẽ có lợi lớn.

Answer 2

Tại thời điểm các chi nhánh bảo trì của bạn không còn tương thích với thân chính nữa, đã đến lúc tạo các nhánh mới cho mục đích đó. Đó là, khi bắt đầu dự án lớn, bạn đảm bảo rằng tất cả các nhà phát triển của bạn đều biết rằng chức năng mới đang đến trong thân chính, để họ có thể lựa chọn nơi thực hiện sửa lỗi tốt hơn. Có lẽ, nếu những thay đổi mã xảy ra trong thân chính là rất quan trọng để làm cho việc bảo trì không hỗ trợ, thì việc bảo trì nên được kết hợp vào thân chính.

Answer 3

Tạo chi nhánh bảo trì và để nó hoạt động như bộ đệm giữa thân cây và các phiên bản-chi nhánh.

Thay đổi đối với các phiên bản-chi nhánh đi vào chi nhánh bảo trì và sau đó chỉ chuyển vào thân cây nếu chúng có thể và ngược lại.

Tôi không nghĩ rằng có một viên đạn bạc. Khi các chi nhánh phân kỳ ngày càng nhiều, chúng sẽ phát triển không tương thích và do đó bạn phải cân nhắc xem bạn sẽ hỗ trợ chúng trong bao lâu. Nếu không, bạn có thể sẽ sửa lỗi nhiều hơn một lần nhưng hơi khác so với các nhánh khác nhau.

Answer 4

Tôi chỉ có thể lặp lại những gì người khác đã nói, đồng thời nhấn mạnh nỗi đau thực sự trong hàng $$ mà hàng đợi vá có thể trở thành.

Nếu bạn có cửa sổ hợp nhất được xác định trước (và lớp phủ sắt), bạn chỉ nên có hai tuần địa ngục để xử lý.

Answer 5

Câu trả lời duy nhất tôi có thể đưa ra là tạo một nhánh bảo trì ngay trước khi bạn bắt đầu tái cấu trúc. Bạn duy trì nhánh mới này như thể nó là một thân cây, kết hợp các thay đổi đến và từ các nhánh phát hành như bình thường. Về sau, bạn phải cẩn thận về việc trộn các thay đổi từ các cơ sở nguồn cũ và mới.

Cách khác là thử một số thứ như MolhadoRef (blog article about MolhadoRef and Refactoring-aware SCM), nếu bạn có thể tìm thấy một hệ thống tương đương sẵn sàng để sản xuất đáp ứng nhu cầu của bạn. Đây là, về mặt lý thuyết, kiểm soát nguồn nhận thức được tái cấu trúc. Tôi đã không nhìn vào nó trong một thời gian nhưng cuối cùng tôi nhớ nó vẫn còn khá xa là bất cứ điều gì nhiều hơn một giấy nghiên cứu và chứng minh-of-khái niệm.

Answer 6

Đây là câu hỏi cuối cùng về giao tiếp nhóm, thay vì câu hỏi ghép/gộp đơn giản.

Bước đầu tiên, như trong tất cả các trường hợp như vậy, đang nhận ra rằng bạn gặp sự cố. Đây là điều bạn đã làm.

Sau đó, bạn cần cảnh báo toàn bộ nhóm về vấn đề này.

Một khi bạn đã làm điều đó, tôi nghĩ rằng có hai con đường khác nhau:

1. Nếu các ngành duy trì được sử dụng thường xuyên, nói mã phát hành khá trưởng thành và lỗi-miễn phí, bạn có thể quyết định một mã đóng băng. Mỗi nhà phát triển phải hoàn thành những gì anh/cô ấy đang làm việc vào ngày 32 tháng 10, và hợp nhất những thay đổi đó trở lại vào thân cây. Các nhánh sau đó sẽ bị đóng hoặc đóng băng. Sau đó, công việc có thể tiếp tục trong thân cây và phần mềm mới có thể được phát hành.

2. Nếu có những thay đổi thường xuyên hoặc khẩn cấp và sửa lỗi trong các chi nhánh, vấn đề này phức tạp hơn. Vẫn cần phải đóng băng mã, hoặc thân cây sẽ bị đóng đinh nhiều lần. Nhưng ở đây, các nhà phát triển vẫn cần phải sửa chữa mọi thứ trong thời gian tạm thời và đưa chúng ra cho khách hàng. Tôi đề nghị rằng mọi thay đổi trong các nhánh sau khi đóng băng mã cố định sẽ được ghi lại trong cơ sở dữ liệu theo dõi lỗi (phải trong mọi tình huống) với một dấu hiệu đặc biệt cho thấy rằng nó đã được cố định trong nhánh N nhưng chưa được sáp nhập vào thân cây. Điều này đòi hỏi phải đăng nhập cẩn thận để mọi chi tiết có liên quan được ghi nhớ.

   Sau khi thân được tái cấu trúc, nhưng trước khi nó được làm sạch, đánh dấu, gắn thẻ và phát hành, hãy xem lại cơ sở dữ liệu lỗi, đặc biệt là các mục được cố định trong nhánh chứ không phải thân cây. Chúng vẫn có liên quan? Bây giờ là lúc để thay đổi mã một lần nữa, nếu cần thiết. Nó có thể có nghĩa là làm việc gấp đôi trong một thời gian ngắn, nhưng hy vọng mã được duy trì nhiều hơn bây giờ.

   Sau khi tất cả các sự cố đã biết được khắc phục, phiên bản mới có thể được giải phóng và các nhánh cũ có thể bị đóng.

Answer 7

Trong thực tế, bạn có thể phải làm thêm để làm cho các thay đổi mới của bạn tương thích ngược.

• Bước 1: Bắt đầu tái cấu trúc thành phần. Với mỗi bước, hãy giữ giao diện cũ xung quanh, nhưng để nó di chuyển cuộc gọi đến triển khai mới. Lưu ý rằng điều này có thể được thực hiện trong một vài bước khi giao diện/API mới được tạo. Kiểm tra đơn vị nên có thể xác minh rằng việc di chuyển từ cũ sang mới hoạt động chính xác, nhưng bước này rất có thể vẫn sẽ phải chịu phí kiểm tra/QA.

• Bước 2: Phiên bản mới đang hoạt động trong quá trình sản xuất; đảm bảo mọi người đều biết về nó. Tại thời điểm này, không có tính năng mới nào được thêm vào phiên bản cũ và tất cả người gọi mới (hoặc đã thay đổi) sử dụng phiên bản mới.

• Bước 3: Tìm mọi thứ (sử dụng công cụ để thực hiện việc này) gọi giao diện cũ và thay đổi mọi thứ để gọi giao diện mới. Điều này có thể phải chịu rất nhiều chi phí kiểm tra/QA. Mỗi người gọi có thể được cam kết/phát hành một tại một thời điểm, mặc dù.

• Bước 4: Tại thời điểm này, phiên bản mới đang hoạt động và không có người gọi nào để truy cập phiên bản cũ. Xóa nó một cách an toàn.

Lưu ý rằng nơi API công khai và bạn không kiểm soát những người gọi nó (ví dụ như Microsoft), bạn có thể không bao giờ có thể đi qua bướC# 2.

Quá trình này có thể chậm và đòi hỏi nhiều kỷ luật, thông tin liên lạc và thử nghiệm. Nhưng trong trường hợp phương án thay thế đang chơi bắt kịp/tích hợp mãi mãi, nó có thể là một lựa chọn hợp lý.

Answer 8

Đây có thể là một gợi ý rất chuyên sâu về công việc, nhưng điều đầu tiên tôi nghĩ đến là kết hợp mọi thứ trở lại thân cây. Mọi thay đổi của mọi người sẽ được hợp nhất trở lại bản sao chính và giữ chúng lại với nhau. Sau đó, refactor trên thân cây tuy nhiên bạn muốn. Bây giờ bạn có một thân cây làm việc, với tất cả các bản sửa lỗi được đặt lại với nhau.

Thật không may, điều này có nghĩa là mọi bản sửa lỗi trong các nhánh bảo trì sẽ cần phải được ném cùng nhau và vào thân cây trung tâm. Tôi nhận ra điều này sẽ là rất nhiều công việc, nhưng tôi nghĩ rằng điều này sẽ cho phép mọi thứ được tái cấu trúc, và bất kỳ cải tiến nào trong các nhánh bảo trì sẽ thuộc về nhánh chính. Tôi có thể ngây thơ về điều này, nhưng tôi đã không thực sự làm việc trên một dự án sản xuất, và cũng không biết chính xác những gì trên các chi nhánh bảo trì. Tôi con số này sẽ làm cho thân cây cập nhật đầy đủ và tất cả các cải tiến bảo trì của bạn sẽ được tích hợp vào thân cây.

Tôi làm theo cách này sẽ tối đa hóa chất lượng của tất cả các nhánh của bạn và việc tái cấu trúc của bạn trải rộng trên tất cả các chi nhánh bạn sẽ chi nhánh sau khi tái cấu trúc. Đây sẽ là một cách hay để đưa nhóm của bạn lại với nhau cho tất cả sự hợp nhất, là tốt.

Answer 9

Tôi thấy hai cách riêng biệt để giải quyết vấn đề này:

1.

thay đổi đáng kể để thân cây (giống như một refactoring lớn) không nên được thực hiện trong cốp xe. Họ nên được thực hiện trong một chi nhánh và sáp nhập trở lại vào thân cây khi họ đủ ổn định.

Định kỳ các thay đổi đối với thân cây phải được hợp nhất với các nhánh bảo trì khác. Lý do chỉ hợp nhất việc tái cấu trúc vào thân cây khi nó ổn định là vì sau đó chúng sẽ được hợp nhất vào các nhánh bảo trì. Tuy nhiên, nếu không có cơ hội để thực hiện những thay đổi này ổn định thì tùy chọn 2 sẽ tốt hơn.

Sau khi thay đổi các chi nhánh bảo trì đã được thực hiện, sau đó chúng có thể được hợp nhất trở lại vào thân cây.

2.

Tạo chi nhánh của các chi nhánh bảo trì (một nhánh cho mỗi nhánh). Điều này sẽ được sử dụng để sáp nhập thân cây với từng nhánh bảo trì.(Lưu ý rằng việc sử dụng SVN externals hoặc tương đương nên được sử dụng để hạn chế số lượng các chi nhánh bảo trì).

Làm tất cả việc tái cấu trúc của bạn trong thân cây và hợp nhất vào các chi nhánh của các chi nhánh bảo trì. Khi bạn giải phóng hoặc nghĩ rằng thân cây ổn định thì hãy hợp nhất các nhánh của bản bảo trì này lại vào các nhánh tương ứng của chúng. Sau đó, chúng có thể được hợp nhất trở lại vào thân cây.

Thực tế, mỗi nhánh bảo dưỡng sẽ trở thành "nhánh phụ".

Lưu ý rằng kịch bản này nêu bật sự cân bằng giữa bảo trì trong tương lai và bảo trì trả trước. Càng nhiều chi nhánh và sự khác biệt bạn có trong mã của bạn, việc bảo trì trả trước nhiều hơn là bắt buộc. Phần tốt là việc bảo trì gia tăng dễ dàng hơn nhiều.

Answer 10

Bạn có phải có có nhiều chi nhánh đang hoạt động không?

Công việc trên thân cây chỉ bắt đầu khi nó đã làm vì kế hoạch dự án cho biết bản phát hành hiện tại sẽ sẵn sàng để vận chuyển, do đó nó đã được vận chuyển?

Bạn có rất nhiều chi nhánh bảo trì vì khách hàng từ chối nâng cấp lên bản phát hành mới nhất vì một số lý do? Nếu có thì hãy giải quyết lý do.

Bạn có quá nhiều bản phát hành cũ vì khoảng cách trước khi bản phát hành chính tiếp theo quá lớn không?

Bạn có tính phí cho khách hàng sẽ không nâng cấp thêm để bảo trì vì chi phí bạn nhiều hơn?

đáp ứng để bình luận:

Microsoft vẫn hỗ trợ Windows XP mặc dù Vista là ra

là rất đúng, Tuy nhiên Microsoft không còn hỗ trợ Window XP SP1 mặc dù XP SP3 là ra.

Đây không phải là màu đen và trắng, ngay cả khi bạn không thể ngừng hỗ trợ phiên bản cũ, bạn có thể giảm số phiên bản cũ mà bạn hỗ trợ. Vấn đề là bán hàng/hỗ trợ thích nói có, nhưng phát triển bị đau, vì vậy bạn cần để có được doanh số bán hàng của bạn/hỗ trợ những người trên mặt.

Answer 11

Cho rằng rất nhiều chi phí sửa chữa lỗi đang tái tạo sự cố và kiểm tra bản sửa lỗi. Bạn có thể viết một bài kiểm tra tự động mà sẽ làm việc trong tất cả các chi nhánh, ngay cả khi sửa chữa mã phải được thực hiện khác nhau cho mỗi chi nhánh?

Answer 12

Tôi nghĩ rằng lựa chọn tốt nhất của bạn là có lặp lại tái cấu trúc. Thay vì làm tất cả việc tái cấu trúc trong một cú đánh lớn trên một nhánh tư nhân, hãy thực hiện một pha tại một thời điểm. Thực hiện một vài thay đổi trên nhánh và sau đó khi bạn biết chúng ổn định, hãy hợp nhất chúng vào thân cây. Các nhà phát triển làm việc trên các chi nhánh khác sẽ chịu trách nhiệm liên tục cập nhật chi nhánh của họ với thân cây.

Việc hợp nhất một tập hợp nhỏ các thay đổi thường sẽ ít hơn nhiều so với việc hợp nhất các nhánh lớn khác nhau một chút. Bạn thường xuyên kết hợp, công việc bạn sẽ phải làm cuối cùng càng ít.

Answer 13

Trong dự án của chúng tôi, chúng tôi không chủ yếu khắc phục các thay đổi trong các nhánh bảo trì phiên bản.Nếu có lỗi và

1. nó xảy ra trong cả thân cây và nhánh chính, chúng tôi sửa nó trong thân cây và sau đó hợp nhất thay đổi với nhánh bảo trì (có thể xảy ra rõ ràng hơn hoặc yêu cầu nhiều công việc hơn, trong đó trường hợp chúng tôi quyết định xem có tốt hơn nếu chỉ sửa lỗi trong bản phát hành mới hơn) không.
2. nó chỉ nằm trong chi nhánh bảo trì, có thể có một số vị vua sửa chữa trong thân cây và chúng tôi đi đến số một.

Answer 14

Vì Greg pointed có một số trường hợp có thể xảy ra.

Tôi muốn thêm trường hợp (2.5) khi hợp nhất thủ công là bắt buộc, nhưng vì bạn đã di chuyển phương pháp ra khỏi vị trí ban đầu và sau đó áp dụng một số thay đổi, rất khó để hợp nhất, đặc biệt nếu "cơ sở" mã cũng đã được sửa đổi trong chi nhánh "bảo trì". Đây không phải là không phổ biến như nó âm thanh, trên thực tế di chuyển một phương pháp đến một vị trí khác nhau và áp dụng một sửa chữa nhỏ là khá phổ biến.

Chúng tôi đã phát triển một công cụ được gọi là Xmerge (hợp nhất chéo), đây là bước đầu tiên hướng tới việc hợp nhất nhận biết về máy tái cấu trúc. Nó không phải là tự động, nhưng nó giúp xử lý các hợp nhất khó khăn liên quan đến mã di chuyển. It's described here và đã được tích hợp trong SCM 2.7.

Chúng tôi đang nghiên cứu: phát hiện di chuyển tự động và cũng có thể "hợp nhất chéo" đối với nhiều tệp đích (bạn chuyển mã sang tệp khác, cũng khá phổ biến).