问对于多个版本的软件来说，处理发布管理的最佳方法是什么？

EN

事实证明，我的工作环境完全一样。我们的系统设置如下：

1. 每个客户端都有自己的数据库。实际上，您正在讨论多租户解决方案。虽然拥有一个数据库到规则-它们都有其优点，但当您想要移动客户端或客户端希望承载他们自己的系统时，或者当您在不同版本之间存在模式差异(这是常见的)时，就会出现问题。解决此问题的唯一其他方法是使用单个数据库，但按模式名称分段(例如，ClientB.Table1...).
2. We，ClientA.Table1使用单个代码库)。我们使用虚拟目录指向客户端正在使用的代码的版本。同一版本上的所有客户端都指向相同的位。然而，我们可能在野外有多个版本。因此，一个客户端可能指向1.0.0.0，另一个客户端可能指向1.0.1.1。
3. 当我们要更新某人时，我们将他们的虚拟目录指向请求发布的版本。物理文件夹是根据其完整的版本号命名的(即1.0.3.4)。该应用程序旨在检测它所期望的数据库版本与它所拥有的数据库版本之间的差异。如果存在差异，则重定向到管理员可以更新数据库架构的页面。所有数据库更改都是脚本化的，并设计为按照适当的顺序执行。我们使用版本号的第三个八进制来表示数据库版本。因此，1.0.1.1表示数据库模式从1.0.0.0。
4. --可能出现的问题是，“为什么要使用虚拟目录？”这涉及到开发方面的核心规则:应用程序代码不能包括任何特定于客户端的数据或设置。具体来说，从应用程序文件夹的根目录下来的任何东西都不能是特定于客户端的。那么，连接字符串呢？这就是我们使用虚拟目录的原因。我们的虚拟设置类似于：

clientsite (or vdir)
    /appname_vdir

客户端站点根文件夹包含具有任何非数据库驱动客户端特定设置(例如连接字符串)的web.config文件。当我们将/appname_vdir指向一个新版本文件夹时，我们不必担心更新连接字符串或任何其他特定于客户端的数据。让这变得困难的是，每个更改都是根据每个客户是否希望以相同的方式进行更改来评估的。如果没有，那么就必须有一种方法来禁用(或不安装)该更改。

理想情况下，您希望承载尽可能多的客户端，因为您可以构建自动化或控制将客户端指向更新版本和执行数据库更新过程的工具。

在某种程度上，我们的计划是构建一种机制，让管理员得到新版本可用的通知。如果它们位于我们的托管环境中，更新将涉及更改适当的虚拟目录路径。如果他们是自己的主机，它将提供一种方式来下载比特，然后进行路径更改。我们还没来得及建造那部分。此外，还可以构建一个管理工具，让支持人员更新人员并确定他们使用的版本。

在我看来，你有两个选择：

• 自己托管所有版本，并智能地区分客户端应该使用哪个版本
• 获取客户端来承载应用程序本身

你自己主持

我想你可以这样做：

• 安装当前正在使用的所有不同版本的
• 有一个域，每个客户端都获得该域的子域。客户端ABC登录到abc.mydomain.com等。
• 使用重定向或URL重写机制，在客户端希望升级、将数据迁移到产品的后期实例时，悄悄地将它们重定向到产品
• 的适当版本，并更改其子域

的重写规则。

请注意，这里我缺少一些细节，因为我对您的设置不太了解，比如每个客户端都在使用自己的数据库，还是您有一个多租户的方法？它们都是使用单独的产品安装，还是使用相同的安装实例，只是获取不同的数据？

客户端托管

这可以是相对直接的管理。您可以将应用程序的ASP.NET部分打包到MSI安装程序中，创建虚拟目录和应用程序池等都可以在MSI中完成。然后，您可以使用像DBGhost这样的数据库升级工具打包数据库--它获取模板(源)数据库，将其与目标进行比较，然后生成使目标与源一致所需的DDL。我知道VS2010的一个版本中也包含了一个工具，但是我没有使用它，也不能对它进行评论。

您的开发人员可以通过向支持团队提供易于使用的方式来帮助减轻升级带来的痛苦。尽可能使用MSI包。尽可能使用工业实力数据库创建/生成工具。如果您由于某种原因不能使用数据库升级工具，那么请确保数据库升级是以良好的方式编写的(即，如果存在对象，则更改object )。如果必要的话，强制执行必须遵循的升级路径--如果客户想从1.6跳到2.0，那么必须先通过1.8 --这使得升级变得更细、更可预测、更易于管理(您维护的升级脚本为1.6->1.8和1.8->2.0，1.6->2.0不必有升级脚本)。

我希望这给你足够的思考-如果你有更多的细节，然后编辑你的帖子，并添加他们。

您考虑过自动化应用程序的更新和部署吗？如果您能够想出一种标准化的方法来打包应用程序，而不管版本如何，那么使用像Nolio (http://www.noliosoft.com)这样的工具就很容易实现自动化。这将使您能够创建每个版本甚至每个帐户的部署过程，并启用“几乎相同”的部署，在这些部署中，差异可以作为每个部署的输入输入。