Đề xuất mô hình phân nhánh cho cùng một dự án nhiều khách hàng

Chúng tôi có một dự án rất lớn bao gồm một số ứng dụng đóng vai trò là cơ sở cho các khách hàng khác nhau.

Mỗi khách hàng có cá nhân hóa sản phẩm riêng, các cột mốc khác nhau, các yêu cầu khác nhau, v.v. và do đó, mỗi dự án sẽ phát triển độc lập dựa trên nhu cầu của chính họ.

Cốt lõi của dự án, tương tự (nhưng không bằng nhau) trong mọi dự án và tổ chức được thực hiện để có các nhóm xử lý từng khách hàng một cách độc lập (nhưng có sự giao tiếp giữa họ khi cần thiết). Cho đến nay, tôi không thể tìm thấy bất kỳ chương trình nào phù hợp với nhu cầu của mình, bằng cách tìm kiếm trên internet hoặc đưa ra một ý tưởng tuyệt vời :)

Cho đến nay, chúng tôi đã làm việc bằng cách lấy sản phẩm phù hợp với mọi nhu cầu, với các chi nhánh cụ thể cho những thay đổi cần thiết, nhưng, mặc dù sản phẩm có kiến ​​trúc tốt, nó dần trở thành một vấn đề lớn. Dưới đây là những vấn đề chính mà chúng ta gặp phải:

• Các cột mốc khác nhau cho mỗi khách hàng: Điều đó có nghĩa là mỗi nhóm phải sản xuất các phiên bản theo thời gian khác nhau mà không có các cam kết còn lại ảnh hưởng đến sự ổn định hoặc sản phẩm của họ.
• Các yêu cầu khác nhau, có thể hoặc không thể ảnh hưởng đến cốt lõi của hệ thống trong một số trường hợp.
• Các đội lớn (hơn 20 thành viên trong nhóm)
• Xử lý các lỗi trong hệ thống: Bạn sẽ làm gì nếu một nhóm tìm thấy một lỗi trong dự án của mình có thể ảnh hưởng đến các khách hàng khác?

Lưu ý: Chúng ta đang nói về một dự án có 10 + M LỘC.

Lưu ý: Chúng tôi đang sử dụng Team Foundation System, Visual Studio 2008 và C # (chủ yếu).

Bất kỳ đề xuất, nguồn hoặc ý tưởng về cách giải quyết tình huống? Có mô hình nào trên thị trường có vấn đề tương tự không?

Trên thực tế, tôi sẽ đề nghị rằng bạn không cần một mô hình phân nhánh, mà là một cách tiếp cận toàn diện hoàn chỉnh để đối phó với các ràng buộc đa chiều liên quan đến hệ thống mà không cần phân nhánh. Trong thực tế, tôi tin rằng sẽ luôn là một vấn đề khi duy trì nhiều hệ thống có một số điểm tương đồng nhưng sẽ phát triển khác nhau trong các nhánh, vì vậy tốt hơn là biến mọi thứ thành một hệ thống duy nhất sẽ phát triển toàn bộ, nhưng bao gồm các cấu hình khác nhau. Điều này có vẻ quá đơn giản, nhưng có nhiều nghiên cứu trong lĩnh vực này, với rất nhiều ứng dụng công nghiệp thành công.

Tên của phương pháp này là Dòng sản phẩm phần mềm hoặc đôi khi là Kỹ thuật dòng sản phẩm . Từ trang Dòng sản phẩm phần mềm của CMU SEI :

Dòng sản phẩm phần mềm (SPL) là một tập hợp các hệ thống chuyên sâu về phần mềm có chung một bộ tính năng được quản lý chung, đáp ứng nhu cầu cụ thể của một phân khúc thị trường hoặc nhiệm vụ cụ thể và được phát triển từ một bộ tài sản cốt lõi chung theo cách quy định .

Ý tưởng chính là mọi yêu cầu, mọi cột mốc, mọi tính năng (một thuật ngữ chính trong miền này) là một phần của hệ thống hoàn chỉnh ở cấp cao nhất. Các hệ thống thực tế được triển khai tại các khách hàng khác nhau về cơ bản là một bộ các tính năng. Tuy nhiên, mỗi tính năng không chỉ là một thành phần vật lý được nghiền trong hệ thống, nó được xác định là tùy thuộc hoặc được bật bởi các tính năng khác (để chọn một tính năng, bạn có thể tự động bao gồm các phụ thuộc của nó, v.v.)

Thay vì sau đó duy trì tất cả các chi nhánh này, cuối cùng bạn sẽ duy trì một hệ thống cùng với một bộ cấu hình dành riêng cho khách hàng.

Thực tế có thể khó hoặc thậm chí là không thể di chuyển sang cách tiếp cận như vậy với một hệ thống rất lớn, nhưng ngay cả khi đó sẽ hữu ích khi điều tra các phương pháp được sử dụng trong SPL để đánh giá cách tiếp cận được sử dụng ít nhất có thể (một phần) tích hợp trong công việc của bạn.

Một số liên kết hữu ích bổ sung:

• Wikipedia: Kỹ thuật dòng sản phẩm
• Nghiên cứu trường hợp của CMU SEI
• Phần mềm Dòng sản phẩm , một trang web có rất nhiều tài liệu giới thiệu.

Khi tôi bắt đầu công việc đầu tiên, tôi đã làm việc cho các dự án tương tự (nhưng với quy mô nhỏ hơn) và chúng tôi đã gặp phải những vấn đề tương tự. Chúng tôi cũng bắt đầu với các yêu cầu xử lý giải pháp chung cho tất cả các khách hàng nhưng điều đó chỉ có thể xảy ra ở cùng một điểm khi các yêu cầu trở nên mâu thuẫn. Chúng tôi đã làm những gì bạn đề xuất và bắt đầu phiên bản riêng cho từng khách hàng. Ngay cả điều này đã giải quyết vấn đề với các yêu cầu và tùy chỉnh, nó trở thành một cơn ác mộng bảo trì để giải quyết các lỗi và thay đổi toàn cầu.

Bởi vì mã trong ứng dụng chỉ tương tự nhau, việc hợp nhất các thay đổi từ phiên bản khách hàng này sang phiên bản khác rất phức tạp và nó yêu cầu kiểm tra lại từng phiên bản riêng biệt (chúng tôi không có kiểm tra tự động!). Nó thường gây ra lỗi hồi quy trong các phiên bản khác nhau. Trong kịch bản của bạn, điều này có thể còn tồi tệ hơn bởi vì một nhóm sẽ giải quyết lỗi trong phiên bản của họ và một nhóm khác sẽ phải hợp nhất thay đổi đó từ phiên bản mà họ không hiểu đầy đủ (chúng tôi là một nhóm làm việc trên tất cả các phiên bản).

Trừ khi bạn có một số cốt lõi chung được chia sẻ, bạn sẽ có những vấn đề tương tự. Trước khi tôi rời công ty, chúng tôi thấy rằng cách tiếp cận của chúng tôi là không chính xác. Để hỗ trợ cho kịch bản phát triển như vậy, chúng tôi cần mô hình dữ liệu và lõi có thể mở rộng được chia sẻ, có thể định cấu hình từ các lớp ứng dụng có thể tùy chỉnh phía trên. Lõi này nên được sử dụng làm cơ sở cho từng tùy chỉnh cụ thể của khách hàng và được duy trì bởi nhóm riêng biệt. Nó sẽ bao gồm một số phức tạp quản lý vì nhiều người quản lý dự án sẽ cần tài nguyên từ cùng một nhóm nhưng đó là cách duy nhất để làm cho kiến ​​trúc nhất quán, kiểm soát toàn bộ quy trình và giữ các phiên bản đồng bộ.

Tôi có thể là cơ sở, nhưng tôi nghĩ rằng những gì bạn đang đối mặt với lõi hệ thống của bạn là cùng một vấn đề mà mọi người phải đối mặt, những người sử dụng các thành phần và cần duy trì và hỗ trợ các bản phát hành phần mềm khác nhau và mỗi bản phát hành khác nhau yêu cầu một bộ khác nhau của các phiên bản thành phần.

Ví dụ

• phát hành 1.0 yêu cầu Thư viện A 1.0, Thư viện B 2.0, Thư viện C 5.6
• phát hành 2.0 yêu cầu Thư viện A 1.0, Thư viện B 3.7, Thư viện C 5.7
• phát hành 3.0 yêu cầu Thư viện A 1.2, Thư viện B 3.7, Thư viện C 5.8

Cách chúng tôi giải quyết vấn đề thành phần là có tất cả các phiên bản của các thư viện trong hệ thống kiểm soát phiên bản của chúng tôi (chúng tôi xây dựng chúng trên nguồn) và để mỗi dự án sử dụng phiên bản thư viện phù hợp bằng cách thay đổi đường dẫn tìm kiếm của chúng (đường dẫn tham chiếu?).

Trong Delphi, điều này được thực hiện dễ dàng thông qua tệp cấu hình của dự án (dưới sự kiểm soát nguồn) nếu bạn không cần các thư viện tại thời điểm thiết kế, nếu không nó vẫn có thể thực hiện được nhưng trở nên khó khăn hơn một chút khi bạn cần chuyển đổi Delphi IDE để sử dụng phiên bản chính xác cũng như các tệp (đăng ký (.reg) dưới sự kiểm soát phiên bản có thể được giải cứu tại đây).

Một giải pháp cho hệ thống cốt lõi của bạn có thể là coi nó như một thư viện mà bạn duy trì các phiên bản khác nhau. Về bản chất, điều đó có nghĩa là bạn cần thiết lập các nhánh khác nhau cho mỗi phiên bản. Sau đó, ứng dụng của khách hàng có thể sử dụng "phiên bản" thích hợp của hệ thống lõi của bạn bằng cách tham khảo thư mục nhánh của hệ thống lõi phù hợp.

Khi các phụ thuộc cho hệ thống cốt lõi của bạn giống với ví dụ trên, thì các phụ thuộc cho các ứng dụng khách của bạn sau đó "chỉ" có một tham chiếu bổ sung: phiên bản của hệ thống cốt lõi của bạn.

Thêm lợi thế với nhiều ứng dụng khách ở đây là bạn có thể chọn khi nào bắt đầu sử dụng một phiên bản cụ thể của hệ thống lõi của mình và bạn không bị ảnh hưởng bởi các thay đổi đối với hệ thống lõi mà bạn chưa sẵn sàng sử dụng cho một ứng dụng khách cụ thể.