Cách tốt nhất để xử lý phiên bản sản phẩm và phân nhánh của các dự án dài hạn là gì?


21

Nói chung, đối với các dự án dài hạn có thể có nhiều bản phát hành trong vòng đời sản phẩm và cần hỗ trợ của các sản phẩm trước đó, cách tốt nhất để xử lý các phiên bản sản phẩm và phân nhánh của cơ sở mã là gì?

Theo một nghĩa cụ thể hơn, giả sử rằng đã có kiểm soát phiên bản phân tán phù hợp (ví dụ như git) và các nhóm có kích thước từ nhỏ đến lớn và nhà phát triển có thể đang làm việc trên nhiều dự án cùng một lúc. Vấn đề chính đang phải đối mặt là có nghĩa vụ hợp đồng hỗ trợ các phiên bản cũ khi chúng tồn tại vào thời điểm đó có nghĩa là sự phát triển mới không thể vá mã cũ (các sản phẩm của Microsoft Office có thể là một ví dụ về điều này, bạn chỉ nhận được các bản vá cho năm tính năng bạn sở hữu).

Do đó, phiên bản sản phẩm hiện tại là một liên lạc phức tạp vì mỗi sản phẩm chính có nhiều phụ thuộc, mỗi phiên bản có thể thay đổi giữa các phiên bản hàng năm. Tương tự, trong khi mỗi sản phẩm có kho lưu trữ riêng, hầu hết các công việc không được thực hiện trên thân nguồn chính mà là trên một nhánh cho việc phát hành sản phẩm năm đó với một nhánh mới được tạo ra khi sản phẩm được phát hành để có thể hỗ trợ. Đến lượt điều này có nghĩa là việc có được cơ sở mã của sản phẩm không phải là vấn đề đơn giản như người ta có thể nghĩ khi sử dụng kiểm soát phiên bản.


2
Nếu không có thêm thông tin về các sản phẩm, dự án và tổ chức của nhóm phát triển, sẽ rất khó để đưa ra câu trả lời cho vấn đề không được ngăn chặn này.
ChrisF

@ChrisF - Tôi đang làm việc trên một số nền tảng nhưng tôi khá chắc chắn rằng các nhà phát triển khác cũng đi chơi ở đây vì vậy tôi cần phải bảo vệ người vô tội / tội lỗi.
rjzii


Đặt cược tốt nhất của bạn sẽ là kiểm tra các câu hỏi khác - như câu hỏi được liên kết ở trên - và sau đó yêu cầu các bit mà họ không bao gồm.
ChrisF

@ChrisF - Vâng, tôi đã đốt cháy một số câu hỏi khác và xếp hàng đọc một số bài dựa trên chúng nhưng điều đó không giúp tôi hiểu được tất cả. Điều lạ là tôi sẽ chỉnh sửa câu hỏi này rất nhiều khi thời gian trôi qua. Vấn đề lớn nhất mà chúng tôi đang gặp phải là cung cấp hỗ trợ cho các bản dựng trước đó, đó là việc sử dụng trung kế cho các cột mốc phiên bản mà những người khác đã đề cập cho git.
rjzii

Câu trả lời:


20

Bao nhiêu (và loại) cấu trúc bạn cần phụ thuộc rất nhiều vào những gì bạn muốn có thể làm. Tìm hiểu những gì bạn không thể sống mà không có, những gì bạn muốn có và những gì bạn không quan tâm.

Một ví dụ điển hình cho các quyết định có thể là:

Những thứ chúng ta không thể sống thiếu:

  • có thể xây dựng lại bất kỳ bản phát hành trước đây bất cứ lúc nào
  • có thể duy trì nhiều phiên bản chính được hỗ trợ của sản phẩm bất cứ lúc nào

Những thứ chúng tôi muốn có:

  • có thể thực hiện phát triển tính năng chính đang diễn ra (cho phiên bản chính tiếp theo) mà không phải lo lắng về việc sáp nhập chi nhánh
  • có thể thực hiện cập nhật bảo trì cho các bản phát hành trong quá khứ

Những thứ chúng ta có thể sống mà không cần:

  • tự động nhập lại các thay đổi từ công việc hiện tại đến các bản phát hành trong quá khứ
  • không bao giờ làm gián đoạn sự phát triển tính năng chính ngay cả trong một vài ngày hoặc một tuần tại thời điểm đó

Nếu mục tiêu trên là mục tiêu của bạn, thì bạn có thể áp dụng quy trình như sau:

  1. Làm tất cả công việc phát triển trên thân của VCS của bạn ("chính" trong git)
  2. Khi bạn gần với một bản phát hành chính, hãy dừng phát triển tính năng chính và tập trung vào sự ổn định của hệ thống trong một tuần hoặc lâu hơn
  3. Khi thân cây có vẻ ổn định, tạo một nhánh cho bản phát hành chính này
  4. Phát triển tính năng chính bây giờ có thể tiến hành trên thân cây, trong khi chỉ sửa lỗi và chuẩn bị phát hành được cho phép trên nhánh
  5. Tuy nhiên, tất cả các sửa lỗi được thực hiện cho chi nhánh trước tiên phải được kiểm tra trên thân cây; điều này đảm bảo rằng chúng cũng sẽ có mặt trong tất cả các phiên bản tương lai
  6. Tạo thẻ (VCS) trên nhánh khi bạn sẵn sàng phát hành; thẻ này có thể được sử dụng để tạo lại bản phát hành bất cứ lúc nào, ngay cả sau khi làm việc tiếp theo trên cùng một nhánh
  7. Các bản phát hành bảo trì tiếp theo cho bản phát hành chính này (bản phát hành nhỏ) hiện có thể được chuẩn bị trên chi nhánh; mỗi cái sẽ được gắn thẻ trước khi phát hành
  8. Trong thời gian đó, phát triển tính năng chính hướng đến phiên bản chính tiếp theo có thể tiếp tục trên thân cây
  9. Khi bạn đến gần với bản phát hành đó, hãy lặp lại các bước trên, tạo một nhánh phát hành mới cho bản phát hành đó . Điều này cho phép bạn có nhiều bản phát hành chính, mỗi bản phát hành trên nhánh riêng của họ, ở trạng thái được hỗ trợ cùng một lúc, với khả năng phát hành các bản phát hành nhỏ riêng biệt cho từng bản phát hành.

Quá trình này sẽ không trả lời tất cả các câu hỏi của bạn - đặc biệt, bạn sẽ cần một quy trình để quyết định những sửa lỗi nào có thể được thực hiện cho nhánh phát hành và để đảm bảo rằng các lỗi không được sửa trên nhánh phát hành trước (các sửa lỗi đó phải luôn luôn được kiểm tra trên thân cây nếu có thể). Nhưng nó sẽ cung cấp cho bạn một khuôn khổ để đưa ra quyết định như vậy.


+1 Tuy nhiên, tôi sẽ thêm rằng kiểm soát nguồn chỉ là một phần trong môi trường của bạn. Tôi sẽ chụp ảnh nhanh VM trên bất kỳ máy chủ xây dựng nào và cũng là ảnh chụp nhanh về môi trường phát triển, để bạn có thể trực tiếp đến môi trường xây dựng thực sự khi bạn cần.
Neal Tibrewala

2
Tôi sẽ làm theo tất cả những điều này, ngoại trừ điểm 5. Khi bạn sửa lỗi trên một nhánh, bạn chỉ nên quan tâm đến việc làm cho nhánh đó hoạt động bình thường. Khi bản sửa lỗi đã được kiểm tra trên nhánh đó, thì bạn có thể hợp nhất sửa lỗi với trung kế hoặc đến nhánh cho phiên bản mới hơn. Sau đó kiểm tra lại và thay đổi bất cứ điều gì bạn cần thay đổi ở đó. (tiếp theo)
Dawood nói phục hồi lại

1
Ví dụ: nếu phiên bản 4.3 đang được phát triển trên thân cây và bạn phải sửa một lỗi trong phiên bản 4.1.x, sau đó sửa lỗi trên nhánh 4.1, kiểm tra nó trên nhánh 4.1, hợp nhất nó với nhánh 4.2, kiểm tra (và có thể sửa) nó trên nhánh 4.2, hợp nhất nó vào thân cây, sau đó kiểm tra (và có thể sửa) nó trên thân cây.
Dawood nói phục hồi lại

1

"Dài hạn" là một chỉ số mà bạn cần phiên bản, nhưng nó không ngụ ý bất kỳ chiến lược phân nhánh và phân nhánh cụ thể nào. Câu hỏi thú vị hơn là có bao nhiêu dòng sản phẩm hoặc dòng phiên bản chính bạn muốn hỗ trợ (phụ thuộc vào hợp đồng với khách hàng của bạn). Ít nhất bạn sẽ cần một chi nhánh cho mỗi dòng sản phẩm / dòng phiên bản chính mà bạn có hợp đồng bảo trì.

Mặt khác, nó phụ thuộc vào quy mô đội của bạn. Nếu bạn có một nhóm phát triển lớn, song song với những người khác nhau làm việc trên các tính năng khác nhau, rõ ràng bạn sẽ cần nhiều nhánh tính năng hơn nếu bạn có nhóm một hoặc hai người. Nếu bạn đang làm việc với một số nhóm lớn hơn, bạn nên cân nhắc sử dụng kiểm soát phiên bản phân tán, điều này làm cho hoạt động song song trên các nhánh khác nhau (và tái hòa nhập chúng sau này vào trung kế) hiệu quả hơn nhiều.


Kiểm soát phiên bản được áp dụng (git) nhưng có một số bất đồng liên quan đến cách xử lý các phiên bản thành phần (có thể là một câu hỏi riêng) và phiên bản sản phẩm. Hiện tại mỗi bản phát hành sản phẩm được cung cấp một tên mã và nhánh mới trong kho lưu trữ được tạo ra, điều đó có nghĩa là mã mới khá xa với thân chính thậm chí không được sử dụng trong một số sản phẩm.
rjzii

1

Git là một công cụ kiểm soát phiên bản - nó quản lý các phiên bản của tệp. Những gì bạn đang theo là một công cụ quản lý cấu hình. Có rất nhiều những thứ có sẵn, nhưng chủ yếu ở mức $$$ cao từ những người như IBM.

Các công cụ kiểm soát phiên bản cung cấp phân nhánh và gắn thẻ, cho phép quản lý cấu hình thô sơ mà không cần hỗ trợ công cụ bổ sung, do đó các nhà phát triển menay không hiểu sự khác biệt. Nhu cầu của bạn có thể vượt ra ngoài những gì GIT được thiết kế để làm.

Tôi không biết, nhưng chắc chắn nó sẽ tồn tại, một công cụ CM cho Git.


0

Câu hỏi này dường như rất giống với một câu hỏi khác mà tôi đã trả lời gần đây.

Nói tóm lại, điều này nghe có vẻ giống như một vấn đề thiết kế và phân phối sản phẩm hơn là vấn đề kiểm soát / phân nhánh phiên bản. Tất nhiên, thật dễ dàng để tôi nói điều đó và khó hơn cho bạn để khắc phục nếu bạn đã khắc phục được vấn đề.

Không biết chi tiết hơn các chi tiết cụ thể của vấn đề cụ thể của bạn. Tuy nhiên, nói chung, nếu tôi có nhiều phiên bản sản phẩm dựa trên cơ sở mã có số lượng mã chia sẻ lớn giữa các sản phẩm, nếu có thể, tôi sẽ tìm cách tái cấu trúc các sản phẩm theo cách có thể mô đun hóa hơn và để đảm bảo rằng các mô-đun sẽ không yêu cầu phân nhánh mã bổ sung. Tôi cũng sẽ xem xét mô hình triển khai của mình, để xem liệu có phương tiện nào tốt hơn để hỗ trợ khách hàng của tôi trong khi vẫn giữ nhiều cơ sở mã thống nhất. Khi cần tùy chỉnh khách hàng cụ thể, độ chi tiết cao hơn của các mô-đun có thể cần thiết để giảm số lượng mã trùng lặp trong hệ thống.

Đó không phải là một nhiệm vụ dễ dàng, nhưng có thể sửa chữa theo từng giai đoạn nếu bạn quản lý công việc tốt và nếu bạn có thể lên lịch công việc để bạn không cần phải "nâng cấp" mọi thứ cùng một lúc.

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.