我公司为房地产机构构建了一个Web应用程序 - 最初使用经典ASP进行编码，并逐步迁移到.NET。基本上，它是一个带有后端数据库的网站，与自定义Windows服务/ dll混合使用。非常适合.NET应用程序。
在我过去的公司中，我们有一个传统的软件设计生命周期。我们构建了产品版本，当我们发布时，所有客户都收到了相同的代码。产品要求通过我们的工程团队进行过滤，发送到QA进行本地升级环境测试，然后推向生产。
该公司为多个客户提供多种版本的产品。基本上，客户A可以在1.5版本上，客户B在1.6上，客户C在2.0上。我们这样做是因为使用我们的应用程序的机构对影响其用户的任何变化都有严格的要求。如果客户对1.5版本感到非常满意，那么他们就会留在那里，即使版本2.0具有所有最新的花里胡哨。客户实际上会推迟升级，因为新的“功能”实际上会造成用户群的混乱。
当你很小的时候支持这种类型的生命周期很好，但随着你成长为数十或数百个客户，它对我们的DEV，DBA，QA造成压力，更不用说我们的支持团队了。现在我们处于这样一种情况：我们每周只能安排6-8个站点，可以根据需求进行更新。这迫使我们让其他站点等待2-4个月，以便在他们的站点上获得更小的更新。任何需要立即关注的生产问题或错误都会使事情变得更加棘手 - 因为已安排接收更新的网站需要排除优先级以便腾出时间。
对不起，这太长了，但感谢任何帮助。我们越早做出一些更改，以便让我们的发布时间表更好。谢谢！
答案 0 :(得分：3)
事实证明，我在完全相同的环境中工作。以下是我们系统设置的方法：
每个客户都有自己的数据库。实际上，您正在讨论多租户解决方案。虽然拥有one-database-to-rule-them-all有其优点，但是当你想要移动客户端或者客户想要托管他们自己的系统时，或者当你有版本之间的架构差异时（这是常见的），它就会成为问题。解决此问题的唯一方法是使用单个数据库，但按模式名称分段（例如ClientA.Table1，ClientB.Table1 ...）。
我们使用单一代码库。我们使用虚拟目录指向客户端使用的代码版本。同一构建中的所有客户端都指向相同的位。但是，我们可能会有多个版本。因此，一个客户端可能指向1.0.0.0，另一个客户端可能指向1.0.1.1。
当我们想要更新某人时，我们将其虚拟目录指向所请求的已发布版本。物理文件夹以其完整版本名称命名（即1.0.3.4）。该应用程序旨在检测它所期望的数据库版本与它具有的数据库版本之间的差异。如果存在差异，则会重定向到管理员可以更新数据库架构的页面。所有数据库更改都是脚本化的，旨在按正确的顺序执行。我们使用版本号的第三个八位字节来指示数据库版本。因此1.0.1.1表示数据库架构已从1.0.0.0更改。
可能出现的问题是“为什么要使用虚拟目录？”这涉及到开发的核心规则：应用程序代码不能包含任何客户端特定的数据或设置。具体来说，从应用程序文件夹的根目录下来的任何内容都不是特定于客户那么，连接字符串呢？这就是我们使用虚拟目录的原因。我们的虚拟设置类似于：
clientsite (or vdir)
/appname_vdir客户端站点根文件夹包含一个web.config文件，其中包含任何非数据库驱动的特定于客户端的设置，例如连接字符串。当我们将/appname_vdir指向新版本文件夹时，我们不必担心更新连接字符串或任何其他客户端特定数据。使这一难的原因是每个变更都要根据每个客户是否都希望以同样的方式改变来进行评估。如果没有，则必须有一种方法来禁用（或不安装）该更改。
理想情况下，您希望尽可能多地托管客户端，因为您可以构建自动化或控制将客户端指向更新版本并执行数据库更新的过程的工具。
在某些时候，我们的计划是建立一种机制，让管理员收到新版本可用的通知。如果它们位于我们的托管环境中，则更新将涉及更改相应的虚拟目录路径。如果他们托管自己的，它将提供下载位然后进行路径更改的方法。那部分我们尚未有时间建立。此外，还可以构建一个管理工具，让支持人员更新人员并确定他们使用的版本。
答案 1 :(得分：0)
我认为你有两种选择：
我想你可以这样做：
请注意，我在这里缺少一些细节，因为我不太了解您的设置，例如每个客户使用自己的数据库，或者您是否有多租户方法？它们都使用产品的单独安装，还是使用相同的已安装实例并只获取不同的数据？
这可以相对直接地进行管理。您可以在MSI安装程序中打包应用程序的ASP.NET部分，创建虚拟目录和应用程序池等都可以在MSI中完成。然后，您可以使用DBGhost之类的数据库升级工具来打包数据库 - 它将获取模板（源）数据库，将其与目标进行比较，然后生成使目标与源一致所需的DDL。据我所知，VS2010的其中一个版本还有一个工具，但我没有使用它，也无法评论它。
您的开发人员可以通过易于他们使用的方式向支持团队提供更新，从而帮助缓解许多升级难题。尽可能使用MSI包。尽可能使用工业强度数据库创建/生成工具。如果由于某种原因无法使用数据库升级工具，请确保数据库升级以良好的方式编写脚本（即如果对象存在，则更改其他创建）。如果需要，强制执行必须遵循的升级路径 - 如果客户端想要从1.6跳到2.0，那么他们必须首先通过1.8 - 这使得升级更精细，可预测且易于管理（您维护1.6的升级脚本 - ＆gt; 1.8和1.8-> 2.0，您不必拥有1.6-> 2.0的。）
我希望这给你足够的思考 - 如果你有更多的细节，那么编辑你的帖子并添加它们。
答案 2 :(得分：0)
您是否考虑过自动化应用程序的更新和部署。如果您能够提供一种标准化的应用程序打包方式，无论版本如何，使用Nolio ASAP（http://www.noliosoft.com）等工具进行自动化将非常容易。这将使您能够为每个版本甚至每个帐户创建部署过程，并启用“几乎相同”的部署，其中差异可以作为每个部署的输入输入。