【问题标题】:Managing Custom Client Releases管理自定义客户端版本
【发布时间】:2009-07-28 19:37:14
【问题描述】:

作为this question 的替代方案,为特定客户管理自定义软件版本的最佳方式是什么?

客户端版本之间的大部分区别在于用户界面的更改,以自定义软件使其看起来归客户端所有。通常情况下,这是一个简单的徽标更改。有时,配色方案也会发生变化。但有时会根据客户端启用或禁用功能。使所有这些版本保持最新并让特定客户的用户轻松使用它们的最佳方式是什么?

此时,我们有五个不同的客户端,每个客户端都有自己的软件版本和自己的安装程序(在安装程序中带有他们的徽标)。这变得难以管理,而且随着越来越多的客户开始使用我们的软件,情况只会变得更糟。

因此,假设链接的问题不是解决方法,那么管理这些版本的最佳方法是什么?

【问题讨论】:

    标签: version-control release-management


    【解决方案1】:

    “这变得难以管理, 而且它只会变得更糟 更多客户开始使用我们的 软件。”

    真正解决这部分的唯一方法是确保您的软件具有支持自定义作为核心产品之上的层的架构。理想情况下,它们只是运行时配置选项(颜色、徽标和启用/禁用非常适合此)。如果您获得(或想要)大量客户,请将可配置性直接推送到核心产品中,并让客户自己进行定制。

    更新时,您构建(和测试)核心产品一次,并通过简单地链接到(引用)已构建的核心产品作为库来构建自定义版本。您可以让每个客户端在一个单独的构建中,或者您可以有一个单独的构建过程,为当前维护的客户端构建所有生成更新(后者可能对更多的客户端更好)。如果您有“香草”版本,您可以将其构建为核心的一部分或与客户端版本一起构建,这取决于您的具体情况。

    根据您的技术,定制层可以独立于核心产品构建。在这种情况下,很少需要重新构建客户端(可能仅针对某些重大更改)——您可以在运行时简单地链接到更新的核心产品。要部署到客户端,您只需部署更新的核心,前提是您有支持此的部署方法。

    如果不了解您的平台,很难说出更多细节,但您已经慷慨地保持这个问题不可知论。

    【讨论】:

      【解决方案2】:
      1. 将源代码树中的通用部分和自定义部分分开。这可以消除绝大多数合并,具体取决于您的测试和发布策略。 总是有一种方法可以抽象出和自定义构建资源,即使您的构建过程必须调用脚本来重写某些文件。

      2. 在良好的源代码管理系统中明智地使用分支。这些并不是毫无意义的“配置管理”系统。它们是专门针对此任务优化的工具,因此如果不建立在一个之上,您可能不会得到更好的东西。

      Subversion 擅长设置多个分支,但最后我检查了它一次只能对单个文件进行 3 路合并。 Perforce 在这个部门非常棒,因为它逐个文件地跟踪您的分支历史,并使用它来自动合并整个分支之间的整组更改。这里真的是猫的睡衣。

      Git 和 darcs 可能有类似的功能,但我没有使用它们。它们似乎是基于这样的想法,即每个工作结帐树都会有一个副本,从一开始就发生所有变化。这对我来说听起来不切实际,因为我需要将一些大型且不断变化的 SDK 置于 SCM 控制之下。

      【讨论】:

        【解决方案3】:

        可以说,唯一的区别需要是您拥有的任何版本的分支,其中包含客户独有的更改。比如:

        /project
           /trunk 
           /branches
              /release-v1
           /customer-branches
              /release-v1-google
              /release-v1-microsoft
         ....
        

        您的客户版本是您的客户版本的分支。由于这些分支永远不会卷入主干或其他发布分支,因此不要污染常规开发 /branches 树。

        【讨论】:

        • 我们目前使用的开发周期非常短,因此通常每周都有“发布”。不会认为需要每周在所有这些分支之间进行合并吗?似乎要管理的东西很多。
        【解决方案4】:

        我想这取决于您需要为每个客户定制的级别,但是您能否让您的基础应用程序根据配置文件“定制”自己?这样您就可以将主干作为完整的应用程序,然后再有特殊的应用程序为每个客户配置控制外观和启用的功能的配置文件,并且您的发布过程将采用正确的配置文件部署到您的安装程序中。

        似乎如果您总是为每个客户提供应用程序的自定义(ish)版本,那么花时间以这种方式扩展应用程序是值得的。

        【讨论】:

          【解决方案5】:

          我设置了一个名为 branding.h 的头文件,其中包含一堆 #ifdef,如下例所示,用于更改需要更改的任何位。在 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++。

          【讨论】:

            最近更新 更多