Quản lý nhiều chi nhánh mã và giao hàng

Question

Tôi làm việc cho một công ty một khách hàng một sản phẩm nhỏ đang chuyển sang công ty một sản phẩm, nhiều khách hàng. Mặc dù chúng tôi chỉ có một khách hàng, chúng tôi có các dự án khác nhau với các ngày giao hàng khác nhau, nhưng đối với mỗi dự án, chúng tôi có thể phân phối bản phát hành hàng tháng mới nhất mà chúng tôi đã giữ trong một chi nhánh mã riêng biệt trong trường hợp chúng tôi ' đã phải cung cấp các bản sửa lỗi cho bản phát hành cụ thể đó.

Gần đây, chúng tôi đã có được một số khách hàng mới và một vấn đề mới phát sinh: Chi nhánh đầu thường sẽ giải quyết (không có chức năng vi phạm) nhiều vấn đề cụ thể của khách hàng và không phải tất cả khách hàng đều muốn thay đổi. thay vì thích các bản sửa lỗi và các tính năng chọn cherry.

Bạn có bất kỳ kinh nghiệm nào về tình huống đó và cách xử lý thực tế mà không bị quá tải bằng cách kiểm tra và làm việc (các bài kiểm tra phát hành hàng tháng của chúng tôi mất khoảng 3 ngày kể từ khi máy tính)? Và phiên bản kiểm soát khôn ngoan, làm thế nào để bạn quản lý (tôi đoán cvs cuối cùng sẽ phải đi ...)?

Answer 1

Có thể sử dụng CVS trong trường hợp này (tôi khuyên bạn nên xem xét các tùy chọn khác như SVN).

Tôi đã làm việc trên một số dự án tương tự. và những gì chúng tôi đã làm là có nhánh Commom, cho các tính năng cốt lõi của hệ thống và chi nhánh "Khách hàng" cho từng biến thể của sản phẩm, theo cách này bạn có thể triển khai các tính năng và sửa lỗi cụ thể của từng khách hàng và vẫn sử dụng các thay đổi tương tự trong "commom "cho tất cả các biến thể của sản phẩm.

Phương pháp này tốn rất nhiều nỗ lực quản lý cấu hình (sáp nhập và xây dựng), vì vậy bạn có thể muốn có một người cụ thể để xử lý các nhiệm vụ này.

EDIT:

Additionaly, bạn nên (nếu đừng đã) có một hệ thống theo dõi lỗi, trong đó bạn nên ghi lại khách hàng/chi nhánh bạn đang làm việc.

Answer 2

Giải pháp đơn giản nhất là cắt sản phẩm thành sản phẩm cốt lõi và mỗi tính năng thành một trình cắm. Bằng cách đó, mọi khách hàng đều có thể chọn lựa các tính năng họ muốn. Nhưng ngay cả giải pháp này cũng có thể nhanh chóng áp đảo một công ty nhỏ. Trong thực tế, bạn thường ở trong tình huống tồi tệ hơn: Bạn có một tính năng mới giúp khách hàng A và chia nhỏ thứ gì đó cho khách hàng B (nói, khách hàng B chưa sẵn sàng sửa đổi cơ sở dữ liệu của họ và tính năng mới không hoạt động mà không có sự thay đổi, vì vậy điều này trong thực tế làm cho phiên bản mới không sử dụng được cho khách hàng B). Nếu bạn lớn, bạn có thể đơn giản bỏ qua khách hàng B.

Vì nó đứng, bạn thực sự cần tìm cách thuyết phục khách hàng của bạn tiếp tục. Cách đơn giản nhất là tiền: Cho họ biết họ sẽ tốn bao nhiêu tiền để có được một sản phẩm được thiết kế riêng và bao nhiêu chúng sẽ tiết kiệm được nếu bạn có thể tìm ra giải pháp phù hợp với mọi người. Mời khách hàng của bạn hơn, xây dựng một danh sách các thay đổi với nhau và có tất cả mọi người đồng ý về kế hoạch.

Ngoài ra, bạn thực sự phải có thử nghiệm đơn vị tự động, vì vậy bạn có thể chắc chắn 100% rằng sản phẩm rời khỏi nhà hôm nay không thể tồi tệ hơn những gì bạn đã bán cách đây bốn tuần.

Ngay cả với hệ thống điều khiển phiên bản tốt nhất hiện có (đối với tôi, đó có thể là git), bạn không thể giải quyết được số người hâm mộ nếu bạn không thể lôi kéo mọi người vào cùng một hướng (ngoại trừ tất nhiên, bạn thực sự có thể tách từng khách hàng thành một trình cắm thêm).

Answer 3

Chúng tôi có một thiết lập tương tự của một (khá chuyên gia) sản phẩm và nhiều (nhưng chỉ có hàng trăm) khách hàng tất cả đều muốn tính năng thú cưng của riêng mình.Theo số điện thoại

Theo tôi có thể thấy bạn có thể đi xuống tuyến đường 'không có giá', nơi sản phẩm của bạn không phải là khách hàng cụ thể và bất kỳ tính năng nào bạn thêm đều là sản phẩm tốt (có thể là của khách hàng) yêu cầu); hoặc bạn đi xuống lộ trình tư vấn riêng biệt, nơi mọi khách hàng đều có phiên bản sản phẩm độc đáo của riêng họ.

Nếu tất cả khách hàng của bạn yêu cầu về cơ bản cùng một sản phẩm thì bạn nên đi xuống tuyến đường đầu tiên và điều đó có nghĩa là tất cả các tính năng đều được chuyển đến tất cả khách hàng.

Tính năng ẩn dễ dàng, việc duy trì nhiều phiên bản đồng thời là một cơn ác mộng !

Một giải pháp có thể hoạt động nếu khách hàng của bạn yêu cầu anh đào chọn tính năng của họ là duy trì chi nhánh cho mỗi người và sau đó rất cẩn thận sao chép các thay đổi có liên quan từ nhánh đầu của bạn.

Điều này có nghĩa là các cam kết của bạn cần phải là nguyên tử nhất có thể - chỉ khắc phục chính xác một vấn đề - và không có thay đổi nào được chuyển trực tiếp đến chi nhánh khách hàng. Nhưng cách tiếp cận đó vẫn rất nguy hiểm.

Answer 4

Chỉ hỗ trợ đầu/thân chính, trừ khi có một nhánh có tính năng sửa lỗi/tính năng không có trong dòng chính.

Tôi biết bạn đã nói một số khách hàng không muốn điều đó, nhưng tôi đã thấy kết quả cuối cùng của việc hỗ trợ nhiều chi nhánh. Bạn không muốn điều đó. Đó là một cơn ác mộng và sẽ làm tê liệt các nhóm phát triển, sản phẩm và thử nghiệm của bạn.

Đừng làm điều đó.

Hãy kiên quyết.