处理具有多个版本的软件的发布管理的最佳方法是什么？ [英] What is the best way to handle release management for software with multiple versions?
问题描述
我公司为房地产机构构建了一个Web应用程序 - 最初使用经典ASP进行编码，并逐步迁移到.NET。从本质上讲，它是一个带有后端数据库的网站，与自定义Windows服务/ dll混合使用。 .NET应用程序非常标准。
My company builds a web application for Real Estate Institutions -- initially coded in classic ASP with an incremental migration to .NET. Essentially, its a website with backend DB, mixed with custom windows services/dll's. Pretty standard for .NET apps.
在我以前的公司中，我们有一个传统的软件设计生命周期。我们构建了产品版本，当我们发布时，所有客户都收到了相同的代码。产品要求通过我们的工程团队过滤，发送到QA进行本地升级环境测试，然后推向生产。
In my past companies, we had a traditional software design life cycle. We built releases of our products, and when we released, ALL customers received the same code. Product requirements were filtered through our engineering team, sent to QA for testing on local staging environments, then pushed to production.
该公司为多个客户提供多个版本的产品。基本上，客户A可以在1.5版本上，客户B在1.6上，客户C在2.0上。我们这样做是因为使用我们的应用程序的机构对影响其用户的任何变化都有严格的要求。如果客户对1.5版本感到非常满意，那么他们就会留在那里，即使版本2.0具有所有最新的花哨功能。客户实际上会推迟升级，因为新的功能实际上会造成用户群的混乱。
This company has multiple versions of our product for multiple customers. Basically, customer A can be on release 1.5, customer B on 1.6, and customer C on 2.0. We do this because the institutions that use our application have strict requirements on anything that changes that affects their users. If a customer is happily fine with release 1.5, they stay there, even though release 2.0 has all the latest bells and whistles. Customers actually push back on the upgrade because the new 'features' actually HURT their user base by causing confusion.
当你小的时候支持这种类型的生命周期很好，但随着你成长为数十或数百个客户，它对我们的DEV，DBA，QA造成了压力，更不用说我们的支持团队了。现在我们处于这样一种情况：我们每周只能安排6-8个站点，可以根据需求进行更新。这迫使我们让其他站点等待2-4个月，以便在他们的站点上获得微小的更新。任何需要立即关注的生产问题或错误都会使事情变得更加棘手 - 因为已经安排接收更新的网站需要优先排序以便腾出时间。
Supporting this type of life cycle is fine when you're small, but as you grow to dozens or hundreds of customers, its a strain on our DEV, DBA's, QA, not to mention our support team. Now we're in a situation where we can only schedule 6-8 sites a week that can be updated as requirements come in. This forces us to make other sites wait 2-4 months to get even minor updates on their sites. Any production issue or bug that needs immediate attention screws things up even more -- because a site already scheduled to receive an update needs to get de-prioritized to make time.
对不起，这太长了，但感谢任何帮助。我们越早做出一些更改，以便让我们的发布时间表更好。谢谢！
Sorry this is so long, but ANY help is appreciated. The earlier we make some changes to get us on a better release schedule the better. Thanks!
推荐答案
事实证明，我在完全相同的环境中工作。以下是我们系统设置的方法：
As it turns out, I'm working in exactly the same environment. Here's how we have our system setup:
-
每个客户都有自己的数据库。实际上，您正在讨论多租户解决方案。虽然拥有one-database-to-rule-them-all有其优点，但是当你想要移动客户端或者客户想要托管他们自己的系统或者你有版本之间的架构差异时（这是常见的），它会成为问题。解决此问题的唯一方法是使用单个数据库，但按模式名称分段（例如ClientA.Table1，ClientB.Table1 ...）。
Each client has their own database. Effectively you are discussing a multi-tenant solution. While having one-database-to-rule-them-all has its advantages, it becomes problematic when you want to move clients or when clients want to host their own systems or when you have schema differences between versions (which is common). The only other approach to this problem is to use a single database but segment by schema name (e.g. ClientA.Table1, ClientB.Table1...).
我们使用单一代码库。我们使用虚拟目录指向客户端使用的代码版本。同一构建中的所有客户端都指向相同的位。但是，我们可能会有多个版本。因此，一个客户端可能指向1.0.0.0而另一个客户端可能指向1.0.1.1。
We use a single code base. We use virtual directories to point to the version of the code the client is using. All clients on the same build are pointing to the same bits. However, we might have multiple versions out in the wild. Thus, one client might be pointed to 1.0.0.0 and another might be pointed to 1.0.1.1.
当我们想要更新某人时，我们指向他们的虚拟目录到请求的发布版本。物理文件夹以其完整版本名称命名（即1.0.3.4）。该应用程序旨在检测它所期望的数据库版本与它具有的数据库版本之间的差异。如果存在差异，则会重定向到管理员可以更新数据库架构的页面。所有数据库更改都是脚本化的，旨在以适当的顺序执行。我们使用版本号的第三个八位字节来表示数据库版本。因此1.0.1.1表示数据库模式已从1.0.0.0更改。
When we want to update someone, we point their virtual directory to the requested released version. The physical folders are named for their complete version name (i.e. 1.0.3.4). The application is designed to detect a discrepancy between the database version it expects and the database version it has. If there is a difference, it redirects to a page where an administrator can update the database schema. All database changes are scripted and are designed to be executed in the proper sequence. We use the third octet of the version number to indicate the database version. So 1.0.1.1 indicates that the database schema changed from 1.0.0.0.
可能出现的问题是为什么要使用虚拟目录？这涉及到开发的核心规则：应用程序代码不能包含任何客户端特定的数据或设置。具体来说，从应用程序文件夹的根目录下来的任何内容都不是特定于客户那么，连接字符串呢？这就是我们使用虚拟目录的原因。我们的虚拟设置类似于：
A question that might arise is, "Why use virtual directories?" This gets into a core rule with respect to development: the application code cannot include any client specific data or settings. Specifically, nothing from the root of the application folder down can be client specific. So, what about connection strings? This is why we use virtual directories. Our virtual setup looks something like:
clientsite (or vdir)
/appname_vdir客户端站点根文件夹包含一个web.config文件，其中包含任何非数据库驱动的客户端特定设置例如连接字符串。当我们将 / appname_vdir 指向新版本文件夹时，我们不必担心更新连接字符串或任何其他客户端特定数据。这种困难的原因在于，每个变更都是根据每个客户是否都希望以同样的方式进行变更来进行评估。如果没有，则必须有一种方法来禁用（或不安装）该更改。
The client site root folder contains a web.config file with any non-database driven client-specific setting such as connection strings. When we point /appname_vdir to a new version folder, we do not have to worry about updating connection strings or any other client specific data. What makes this tough is that every change has be evaluated in the light of whether every client will want that change in the same way or not. If not, then there has to be a means to disable (or not install) that change.
理想情况下，您希望尽可能多地托管客户端，因为您可以构建工具，自动化或控制将客户端指向更新版本并执行数据库更新的过程。
Ideally, you want to host as many clients as you can because you can build tools that automate or control the process of pointing clients to an updated version and executing the database update.
在某些时候，我们的计划是建立一种机制，让管理员收到新版本可用的通知。如果它们位于我们的托管环境中，则更新将涉及更改相应的虚拟目录路径。如果他们自己托管，它将提供下载位然后进行路径更改的方法。那部分我们还没来得及建设。此外，还可以构建一个管理工具，让支持人员更新人员并确定他们使用的版本。
At some point, our plan is to build a mechanism to let an administrator be notified that a new version is available. If they are in our hosted environment, updating would involve changing the appropriate virtual directory path. If they are hosting their own, it would provide a means to download the bits and then do the path change. That part we haven't yet had time to build. In addition, it is also possible to build a management tool to let support folks update people and determine what version they are using.
这篇关于处理具有多个版本的软件的发布管理的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
