作为this question的替代方案，为特定客户端管理自定义软件版本的最佳方法是什么？
客户端版本之间的大多数差异都是对用户界面的更改，以使软件自定义为客户端所拥有的软件。更常见的是，这是一个简单的徽标更改。偶尔颜色方案也会改变。但有些情况会根据客户端启用或禁用功能。什么是使所有这些版本保持最新并使其易于特定客户的用户使用的最佳方法？
此时我们有五个不同的客户端，每个客户端都有自己的软件版本和自己的安装程序（在安装程序中都有自己的徽标）。这变得很难管理，随着越来越多的客户开始使用我们的软件，它只会变得更糟。
因此，假设链接问题不是可行的方法，那么管理这些版本的最佳方法是什么？
答案 0 :(得分：3)
“这变得很难管理， 它会变得越来越糟糕 更多客户开始使用我们的 软件“。
真正解决这一部分的唯一方法是确保您的软件具有支持自定义的架构，作为核心产品之上的层。理想情况下，它们只是运行时配置选项（颜色，徽标和启用/禁用是完美的）。如果您获得（或想要）大量客户端，请将可配置性推送到核心产品中，并使客户端能够自行进行自定义。
更新时，您构建（并测试）核心产品一次，并通过简单地链接到（引用）已经构建的核心产品作为库来构建自定义版本。您可以将每个客户端放在单独的构建中，或者您可以使用单个构建过程为所有当前维护的客户端构建生成更新（后者可能更适合大量客户端）。如果您有一个“vanilla”版本，您可以将其构建为核心版本或客户端版本，它将取决于您的特定情况。
根据您的技术，可能可以独立于核心产品构建自定义层。在这种情况下，很少需要客户端重建（可能只对某些重大更改） - 您可以在运行时链接到更新的核心产品。对于部署到客户端，如果您有支持此功能的部署方法，则只需部署更新的核心。
在不了解你的平台的情况下很难说出更多细节，但你慷慨地保持这个问题不可知。
答案 1 :(得分：1)
分隔源树中的公共部分和自定义部分。这可以消除绝大多数合并，具体取决于您的测试和发布策略。 始终是一种抽象和自定义构建资源的方法，即使您的构建过程必须调用脚本来重写某个文件。
在良好的源代码管理系统中明智地使用分支。这些不是什么都不称为“配置管理”系统。它们是针对此任务进行优化的工具，因此如果不构建它们，您可能无法获得更好的效果。
Subversion擅长设置多个分支，但最后我检查它一次只能在一个文件上进行3路合并。 Perforce在这个部门非常棒，因为它可以逐个文件地跟踪您的分支历史记录，并使用它来自动合并整个分支之间的整组更改。这真的是猫的睡衣。
Git和darcs可能有类似的力量，但我没有使用它们。它们似乎基于这样一种想法，即每个工作结帐树都将拥有自开始以来所有变化的副本。这对我来说听起来不切实际，因为我需要在SCM控制下保留一些大而且不断变化的SDK。
答案 2 :(得分：0)
可以说，唯一的区别必须是您拥有的任何版本的分支，以及客户中唯一的变化。例如：
/project
/trunk
/branches
/release-v1
/customer-branches
/release-v1-google
/release-v1-microsoft
....
您的客户端版本是客户版本的分支。由于这些分支不会被卷入主干或其他发布分支，因此不要污染常规开发/分支树。
答案 3 :(得分：0)
我想这取决于每个客户端所需的自定义级别，但是你可以让你的基础应用程序根据配置文件“自定义”吗？所以你可以让trunk成为完整的app然后有特殊的控制外观和控制的每个客户的配置文件感觉，以及启用的功能，您的发布过程将在安装程序中部署正确的配置文件。
似乎如果您总是为每个客户端提供应用程序的自定义（ish）版本，那么以这种方式扩展应用程序是值得的。
答案 4 :(得分：0)
我设置了一个名为 branding.h 的头文件，其中包含一堆#ifdefs，如下例所示，可以更改需要更改的位。在Visual Studio中，可以使用定义的相应客户端符号轻松设置多个构建。
#if defined BRAND_CLIENT1
# define COMPANY_NAME "Client 1"
# define PRODUCT_NAME "The Client 1 Widget App"
# define LOGO_FILE "res/logoClient1.ico"
#elif defined BRAND_CLIENT2
# define COMPANY_NAME "Client 2"
# define PRODUCT_NAME "The Client 2 Super Widget App"
# define ENABLE_EXTRA_MENU
# define LOGO_FILE "res/logoClient2.ico"
#endif
这当然是假设C ++。