.net 对于具有多个版本的软件，处理发布管理的最佳方法是什么？

我的公司为房地产机构构建了一个web应用程序——最初是用经典的ASP编写的，并增量迁移到.NET。本质上，它是一个带有后端数据库的网站，混合了定制的windows服务/dll。对于.NET应用程序来说，这是相当标准的

在我过去的公司里，我们有一个传统的软件设计生命周期。我们构建了我们产品的发行版，当我们发布时，所有客户都收到了相同的代码。产品需求通过我们的工程团队进行筛选，发送给QA在本地暂存环境中进行测试，然后推向生产

这家公司为多个客户提供了我们产品的多个版本。基本上，客户A可以在1.5版上，客户B可以在1.6版上，客户C可以在2.0版上。我们这样做是因为使用我们的应用程序的机构对影响其用户的任何更改都有严格的要求。如果客户对1.5版满意，他们会留在那里，即使2.0版拥有所有最新的功能。客户实际上会拒绝升级，因为新的“功能”实际上会造成混乱，从而伤害他们的用户群

当您很小的时候，支持这种类型的生命周期是很好的，但是当您成长为几十个或数百个客户时，它会给我们的开发人员、DBA、QA带来压力，更不用说我们的支持团队了。现在我们的情况是，我们每周只能安排6-8个站点，这些站点可以随着需求的到来而更新。这迫使我们让其他网站等待2-4个月才能在他们的网站上获得甚至微小的更新。任何需要立即关注的生产问题或bug都会把事情搞得更糟——因为已经计划好接收更新的站点需要取消优先级以腾出时间

---

对不起，时间太长了，但我们非常感谢您的帮助。我们越早进行一些更改，以使我们的发布时间表越好。谢谢

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

• 自己托管所有版本，并智能地区分客户端应使用的版本
• 让客户端自己托管应用程序

自己主持 我想你可以这样做：

• 安装当前使用的所有不同版本
• 如果有一个域，每个客户端都会得到该域的一个子域。客户ABC登录ABC.mydomain.com等
• 使用重定向或URL重写机制以静默方式将它们重定向到产品的相应版本
• 当客户端想要升级时，将其数据迁移到产品的后续实例，并更改其子域的重写规则

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

客户端托管 这可以相对直接地进行管理。您可以将应用程序的ASP.NET部分打包到MSI安装程序中，创建虚拟目录和应用程序池等都可以在MSI中完成。然后，您可以使用数据库升级工具（如DBGhost）来打包数据库—它将模板（源）数据库与目标数据库进行比较，然后生成使目标数据库与源数据库一致所需的DDL。我知道VS2010的其中一个版本中也包含了一个用于此目的的工具，但我没有使用过它，也不能对此发表评论

---

您的开发人员可以通过以一种易于使用的方式向支持团队提供更新来帮助减轻许多升级痛苦。尽可能使用MSI软件包。尽可能使用industrial strength数据库创建/生成工具。如果由于某种原因无法使用数据库升级工具，请确保以良好的方式编写数据库升级脚本（即，如果对象存在，则使用alter else create）。如有必要，强制执行必须遵循的升级路径—如果客户机希望从1.6跳到2.0，那么他们必须先通过1.8—这使升级更精细、更可预测且更易于管理（您为1.6->1.8和1.8->2.0维护一个升级脚本，您不必为1.6->2.0创建一个脚本）

---

我希望这能给你足够的思考——如果你有更多的细节，那么就编辑你的文章并添加它们。

事实证明，我在完全相同的环境中工作。以下是我们的系统设置：

每个客户机都有自己的数据库。实际上，您正在讨论多租户解决方案。虽然使用一个数据库来管理所有数据库有其优点，但当您想要移动客户端，或者客户端想要托管自己的系统，或者在版本之间存在模式差异（这是常见的）时，就会出现问题。解决此问题的唯一其他方法是使用单个数据库，但按模式名称分段（例如ClientA.Table1、ClientB.Table1…）

我们使用单一的代码库。我们使用虚拟目录来指向客户端正在使用的代码版本。同一版本上的所有客户端都指向相同的位。然而，我们可能有多个版本在野外。因此，一个客户端可能指向1.0.0.0，另一个客户端可能指向1.0.1.1

当我们想要更新某人时，我们将他们的虚拟目录指向请求的发布版本。物理文件夹以其完整的版本名命名（即1.0.3.4）。该应用程序设计用于检测预期的数据库版本与其拥有的数据库版本之间的差异。如果存在差异，它将重定向到管理员可以更新数据库架构的页面。所有数据库更改都编写了脚本，并设计为按正确的顺序执行。我们使用版本numb的第三个八位组

clientsite (or vdir)
    /appname_vdir