Một cách thực tế để xử lý các bản vá phần mềm dành riêng cho khách hàng là gì?

Tôi đang cố gắng thu thập những cách hiệu quả mà những người khác đã giải quyết vấn đề sau. Tại nơi làm việc, chúng tôi đã buộc phải phát hành một bản vá phần mềm (sẽ được cài đặt trên các hệ thống của người dùng cuối) mà chúng tôi chỉ muốn hiển thị cho một khách hàng cụ thể. Mã tùy chỉnh nằm trong nhánh kiểm soát nguồn của chính nó. Vấn đề là chúng tôi có hai dòng mã song song (và xây dựng tập lệnh) để giữ đồng bộ và mỗi khi chúng tôi vá mã gốc, chúng tôi phải vá và kiểm tra mã dành riêng cho khách hàng.

Tôi tò mò, làm thế nào để các tổ chức khác xử lý tình huống này? Chúng tôi sẵn sàng cho các giải pháp kinh doanh và không chỉ các giải pháp kỹ thuật (liên quan đến kiểm soát nguồn). Ví dụ: chúng tôi đã nói về việc nói với khách hàng rằng họ không thể nhận được cập nhật trên chi nhánh đó.

Chiến lược phân nhánh của chúng tôi là như thế này (dựa trên Hướng dẫn phân nhánh của Visual Studio TFS , mặc dù chúng tôi đang sử dụng Subversion cho nó)

Khi bạn bắt đầu đưa ra các bản vá cụ thể của khách hàng, bạn đã ngay lập tức tạo ra một phiên bản mới của sản phẩm phải được duy trì cùng với nó. Điều đó có nghĩa là những thay đổi phải được lan truyền giữa hai phiên bản. Thông thường các bản vá cụ thể của khách hàng là các tùy chỉnh nên được sở hữu bởi khách hàng, bao gồm cả mã nguồn.

Dường như một bản vá để sửa một cái gì đó sẽ không thể đưa nó vào nhánh chính trừ khi đây là một sửa chữa tạm thời ít hơn tối ưu cho một vấn đề tức thời. Nếu đó là trường hợp thì bản vá sẽ chỉ cần được duy trì cho đến khi sửa chữa dự kiến ​​làm cho nó vào dòng chính.

Dường như với tôi khóa là "hiển thị" - điều gì về việc không có một nhánh mã riêng biệt, mà là một tùy chọn cấu hình thay đổi hành vi?

Bạn có thấy điều này là một điều ngắn hạn hay dài hạn? Thực tế là doanh nghiệp đã quyết định tiếp nhận khách hàng này vì vậy trong thời gian ngắn, đó là quyết định kinh doanh chủ yếu được giải quyết bằng thực tiễn kinh doanh (chấp nhận trả thêm chi phí / tính phí cho khách hàng).

Nếu lâu dài thì có lẽ bạn sẽ thấy tiết kiệm nếu bạn tính lại phần mềm để dễ dàng đáp ứng nhu cầu của khách hàng thông qua cấu hình (hoặc thiết lập, v.v.).

Nếu nó tương đối ngắn hạn, bạn sẽ sớm hợp nhất những thay đổi đó trở lại vào nhánh chính / phát triển và tất cả người dùng cũng sẽ thấy những thay đổi đó có thể được chấp nhận để hoạt động trong giới hạn của tình huống hiện tại của bạn. Giống như tôi đã nói quyết định phải làm gì nên được đưa ra khi quyết định thích nghi với khách hàng được đưa ra.

Mẩu chuyện dài. Sửa chữa lâu dài về mặt kỹ thuật, ngắn hạn đối phó với nó.

Tất nhiên có một điểm mà đó là tung đồng xu. Nếu bạn đang ở thời điểm đó thì tôi sẽ làm bất cứ điều gì các nhà phát triển thích.

Chúng tôi cũng sử dụng lật đổ - và chúng tôi gặp chính xác kịch bản như vậy.

Dưới đây là một số điểm chính cần nhớ:

1. Trong khi cần thiết người ta phải tránh các chi nhánh cụ thể cho khách hàng, nhu cầu phải được giảm thiểu càng tốt; luôn luôn hỏi liệu có thể khái quát hóa giải pháp có thể chỉ hoạt động cho tất cả.

2. Chi nhánh cụ thể của khách hàng phải bắt nguồn từ một bản phát hành mới. Giả sử bạn có phiên bản 1.2 và hơn bạn đã bắt nguồn từ phiên bản 1.2.1 đến 1.2.11 - các chi nhánh khách hàng nên được cho phép tất cả các bản vá do đó chi nhánh khách hàng phải tương thích với phiên bản chính.

3. Chi nhánh cụ thể của khách hàng cần được tạo mới khi bạn bắt đầu một phiên bản không tương thích mới. Điều không may là bằng cách nào đó bạn có thể yêu cầu làm lại công việc. Một giải pháp có thể là tạo ra tất cả các bản vá từ các chi nhánh khách hàng cần được trích xuất và bất cứ điều gì xảy ra để vẫn tương thích đều có thể được áp dụng cho chi nhánh khách hàng mới.

4. Luôn luôn, trong mọi trường hợp, bạn nên đẩy các thay đổi cụ thể của khách hàng trở lại để phát hành chi nhánh hoặc thân cây. Tuy nhiên, lý tưởng nhất là người ta nên cố gắng khái quát hóa công việc theo cách giảm bớt công việc cụ thể của khách hàng đó.

Tôi đã cố gắng kết hợp những ý tưởng này lại với nhau để thể hiện trong :

Làm thế nào về việc giới thiệu một cơ chế mở rộng vào mã của bạn?

Mã chính của bạn có:

class Foo
{
}

Khi chương trình khởi chạy, nó sẽ kiểm tra DLL / moral tương đương, trong thư mục khởi động của nó để biết các tùy chỉnh cục bộ. Nếu tìm thấy một, nó tải và nó có thể chứa phiên bản Foo cụ thể của công ty

class FooForABC : Foo
{
}

FooForABC thực hiện hành vi tương tự như Foo nhưng ghi đè các chức năng khi cần thiết để cung cấp hành vi cụ thể mà ABC cần. Kỹ thuật này phải đủ linh hoạt để xử lý bất kỳ kịch bản nào bạn cần hỗ trợ.