您可以采取什么措施来减少实时网站的部署错误数量？

我敢肯定你们中的很多人都遇到了这个问题。网站或Web应用程序正在运行并且正在运行。您想上传下一个版本，但是您还没有弄清所有内容，例如在配置文件中将值设置为false，将另一条记录插入数据库中以及进行许多次要的工作，这些工作有时可以计算20个或更多的参数。

上传新版本后，一切都会中断。现在，解决问题可能只需要20分钟，但是您所能忍受的总体压力以及对公司的财务和商誉损失有时也不会忘记。

有什么方法可以减少由新版本部署的初始配置引起的这些类型的错误？

PS：请不要提及检查清单，因为我们已经有了它们。检查清单的问题在于，它们应该始终得到更新，但不会更新。

两件事情：

• 过渡环境，类似于您在其中测试部署的实时环境。
• 部署后对此环境进行了充分的测试。自动化和非自动化。

还有其他事情可以做。

我建议阅读由Troy Hunt撰写的有关自动部署的5部分博客系列。他使用的工具是特定于MS堆栈的，但是这些概念是通用的。

我想知道，为什么没有人提到版本控制 -这是在更新/升级时使您免于麻烦的最重要方法之一。

首先，您的部署应该只是存储库中稳定分支的克隆。包括配置文件，SQL文件，安装/更新脚本在内的所有内容都必须受版本控制。

其次，您需要具有“某种”暂存区-可以是任何东西-本地服务器，您刚刚产生的临时虚拟云服务器，非常简单的虚拟主机设置或完全成熟的自定义应用程序您与主应用程序一起维护。此“临时区域”与您的“开发区域”之间的区别在于，前者更紧密地建模（或模拟）您的实际部署环境。例如，您可以使用Apache模块在PHP 5.3.x上进行开发，但是由于您的主机是具有FCGI的PHP 5.2.x，因此登台区域必须相同。

然后，您首先在开发环境上编写和测试更新。将这些更改合并到暂存区存储库中，然后再次进行测试。此时，您可以对配置进行任何更改以适合您的部署-由于它是受版本控制的，因此不会丢失任何内容，并且在遇到问题时始终可以还原。

最后，将暂存区域更改合并到实时部署副本上。

临时区域的复杂性应反映应用程序的复杂性和范围。但是在任何情况下，版本控制都是必不可少的。

当然，如果您不使用版本控制-这都不适用-但这就像在Logo中编写数据库一样幼稚。

根据建议，使用登台系统。这使您有机会在实际环境中测试您的更改。

这又提出了另一点：拥有测试人员。测试我自己编写的内容不会发现与其他人测试我的应用程序时一样多的错误。

另一件事：自动化您的部署过程。使用ant migration进行数据库迁移，通过capistrano等自动从svn部署最新版本。部署某些内容时，您无需要做更多的事情，而只需单击一下，一切便会自动完成。尤其是对于需要一些配置设置的网站，部署所需的手动步骤是一个噩梦，并且可能会出现一些问题。

对于绝对绝对不能中断的事情，请考虑拥有A和B系统，并在升级和测试B时使用负载平衡器将所有请求路由到A，然后在更新A时将所有请求路由到B。

要获得加分，请添加C并确保您的系统在地理位置上是分开的，这样地震不会同时导致其中的2个被淘汰。

对于许多应用程序，我承认这太过分了。

这也使您需要执行的任何事务管理变得复杂，但是问题并非无法解决。

是的，您需要在其中进行所有步骤的测试或登台环境，但是必须为单独的环境保留单独的配置文件。

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

基本上，在我的构建和部署脚本中，我采用一个环境属性，该属性将获取特定于环境的元数据文件（如XML文件），并在打包之前在我的构建位置中替换它们。进一步，在我的部署脚本中，我将在数据库更新中查找所有SQL文件，并针对该环境在已配置的数据库上执行这些文件。

我可以通过自定义构建任务来完成此操作，但是实际上我只是使用一些JUnit测试来为我完成此操作。如果发生任何SQL异常，则测试将失败，因此部署将失败。一般来说，SQL脚本也具有智能，如果环境中已存在必要的数据，则它们会跳过插入或更新。

对于在特定环境下运行的批处理或shell脚本，我也有一个类似的目录。

您问题的全部内容是这样的：它们应该始终得到更新，但不会更新。

这些配置可驱动您的自动化构建和部署，因此，如果不更新它们，则构建会失败，并且会通过电子邮件向经理发送。对于团队来说，维护特定版本的构建和部署配置与检入已编译的代码一样重要。两种违规行为都会破坏构建。

简而言之，更大程度地采用持续集成（CI）原则将有助于消除生产发布的痛苦。

1）首先部署到测试站点并测试您的更改

2）将所有配置保存在配置文件中（Web config或类似文件）。然后，此配置应特定于应用程序，并且永远不会被覆盖。然后讨论所有更改，而不是忘记更改应该与测试有所不同的内容。

除了上述关于建立预生产环境并使用自动化测试的出色建议之外：

降低代码库的复杂性。通常，更少的代码意味着更少的错误，更容易找到它们。这是重构，关注点分离等背后的哲学。

分割代码库。一种常见的方法是将其分为：

• 一些缓慢变化的核心部分，在整个网站上共享
• 许多叶片部分的变化速度可能更快，但每个叶片部分只会影响较小的部位

对代码库的这种了解使您可以将开发和测试重点放在核心部分上，因为那里的错误会产生最严重的影响。

执行良好的发布全部与计划和沟通有关。因此，在进行发布之前，请考虑以下问题：

1. 该发行版可能要花多长时间，并且在发行进行期间让人们继续与我的产品交互会有任何风险吗？如果系统存在风险，请考虑使系统脱机并在其位置放置“系统正在维护中”消息。

2. 您是否需要任何客户提前通知发布？在发布进行期间，是否需要告诉他们可能的服务中断或性能下降？就我个人而言，我总是过分沟通并告诉所有客户有关公共博客或类似场所即将发布或发布维护窗口的信息。

3. 该发布有误，我有什么应急计划？例如，如果发行情况不佳，我们是否应该回滚并将系统还原到最大限度地减少离线时间的方式？如果是这样，是否充分记录了回滚版本的步骤？还是应该请合适的人员值班或在手，以帮助解决出现的问题。我个人认为，进行任何发行计划的最佳方法是假设发行会出问题。这样，我迫使自己提前考虑其中的一些问题。

接下来，在执行发行版时，确保发行版顺利运行的最佳方法之一是练习，练习，练习和记录在执行过程中遇到的所有问题。因此，在将新代码部署到生产环境之前，请先练习将代码部署到安全，正确的沙盒过渡环境中。有负责将其部署到生产中的人员，对阶段进行测试部署。考虑一下这是您的彩排，如果这是真实的话，请像对待自己一样进行。记录您在每一步中所做的一切；记录执行的每个命令，运行的任何SQL代码，修改的文件以及修改的方式，并记录过程中每个步骤的内容，以查看过程执行是否正确。如果并且当您遇到某种问题时，请记录您为解决该问题所做的工作。

然后，练习部署完成，查看您的注释，看看是否可以优化流程以消除错误。然后再做一遍。继续练习直到执行发行变得像遵循简单的说明表那样的例行程序，例如“登录到此计算机，执行此命令；然后登录数据库并执行此SQL命令；然后...”

上面列出的是操作或发布管理团队可以做的事情，以帮助发布顺利运行。但是工程人员可以做些什么来帮助最大程度地降低发布中的风险？

1. 保持发行量小。简而言之，发行版包含的代码更改集越复杂，发行版的风险就越大。通过计划在同一时期内拥有大量的小版本，而不是少量的大版本，对您的运营团队有所帮助。

2. 测试，测试，测试。不要只在质量保证环境中测试您的代码，还应使用登台环境来测试您的软件。通常，一些错误与代码本身几乎没有关系，或者与代码本身无关，而根本原因却在于环境本身的配置（或两者的某种混合）。要找到这些问题，您需要在与生产（也称为登台）密切相关的环境中测试代码。

最后，有时候最重要的不是我们如何防止事情出错，而是当事情出错时我们如何表现自己。因此，我认为在您的公司中建立围绕运营透明度的文化非常重要。不要试图向客户隐瞒问题，快来吧。积极使用Twitter，让客户知道您的运营团队当前是否知道并正在解决问题（Lighthouse非常棒！）。考虑发布服务的“状态”页面，供客户参考以查看是否有任何错误（TypePad提供了一个很好的示例）。最重要的是，总是在沟通过度方面犯错。您的客户将为此感谢您。

这里的许多答案已经告诉您如何实施针对该问题的特定解决方案，但是据我所知，真正的问题不是正确迁移/更新网站之一。它背后的设计/架构可能很脆弱。

如果是这样，则必须调整系统的体系结构，使其足够健壮，即使配置设置发生更改或设置不正确，也可以继续正常运行，并且在发生配置设置时也会优雅地降低性能。理想情况下，如果您以需要新数据库列的方式添加了新功能或更改了旧功能，则即使该列丢失了，您的站点也可以正常工作（也许没有新功能或旧功能的降级形式） 。您的客户不应该亏钱-最糟糕的是，他可能不会从您提供的改进中获得新的收益。

如果您的系统足够脆弱，以至于配置设置可能会导致此类严重问题，那么程序更新就不会成为问题的唯一来源-弄清楚如何安全地执行更新只会增加当故障源于您时遭受的损失一个不同的来源。