如何在不感到极端焦虑的情况下自动化生产部署？

在我们的工厂中，我们使用SVN进行源代码控制，使用Cruise Cruise进行CI处理处理针对我们的开发，测试和集成环境的自动构建和部署。

所有这些都可以顺利进行，但是由于硬件和资源的限制，我们的集成环境不是像生产环境那样的2服务器负载平衡环境。尽管其他所有条件都相同，但这将是我们的集成和生产环境之间的唯一区别（尽管很大！）

从理论上讲，区别是我们的应用程序服务器的配置稍有不同，并且部署脚本仅需将构建工件放到两台服务器中，而不是仅仅放到两台服务器中，但是为什么我如此紧张地自动化我们的生产部署？

我通常不是控制狂，但是我总是感到需要手动将生产部署到生产中。我从同事那里听说，这通常是Really BAD Thing™，但他们没有提出反对的理由。

我知道，当我手动执行操作时，可以看到我正在物理上复制正确的文件，正在物理上关闭应用程序服务器并确保它们成功关闭，我正在物理上启动服务器，然后进行物理检查以创建日志确保启动正常并且部署成功。它使我安心。

对于自动脚本化生产部署，反对此OR参数的参数是什么？

有一些明显的反对意见。

1. 如果你离开会怎样？是否已仔细记录了所有这些信息，还是大部分都在您的脑海中。自动化脚本是其他人接管的更好的地方。

2. 每个人都会犯错。有时候部署人员会很累，什么都不注意。是的，理想情况下，部署只能在一个愉快而平静的地方进行，而且要花费大量时间。在实践中，当尝试推出紧急修复程序时，可能会急于适应它们并感到压力。这是最可能犯错误的时间，也是最昂贵的时间。如果部署是单个脚本，则错误的可能性是有限的。

3. 时间。随着部署变得越来越复杂，需要做的工作量也在增加。脚本只需要启动，手动检查，然后手动切换即可（您也可以自动执行此操作，但是我也有些偏执：）。

您可以获得最好的世界：过程验证和自动化的可靠性使您高枕无忧。

编写部署脚本。然后，仔细检查并手动确认进程已启动，文件已删除等。换句话说，编写您自己的质量检查脚本只是为了验证自动化步骤1-X是否确实发生。

我认为这里的关键是：为什么您认为无法编写验证过程脚本？

我的部署脚本不只是推送存档并重新启动服务。他们在部署的每个步骤中都会打印出许多用颜色编码的信息，并在结束时为我提供事件摘要。它使我知道进程已启动并且正在运行，主页提供了200个状态代码，并且所有机器和服务都可以正常运行。然后，我有一个单独的服务，该服务不属于脚本的一部分，该脚本监视日志文件，4xx和5xx级错误以及关键站点指标。然后，如果出现严重的负面影响，它会通过各种可能的媒介（电子邮件，txt消息和警报）对我大喊大叫。

在那和运行测试的CI服务器之间，我实际上部署并忘记了这种自动化级别。推送后，我什至不浏览网站上的单个页面，因为该过程现在非常可靠，这不仅使我可以按需部署，而且还可以让项目中的新开发人员实时更新加入网站后的几分钟之内。过去，在提交通过所有内容的master / trunk分支后，我甚至使CI服务器自动部署到生产环境。这就是我对工具的信心。

你也应该

您是否还通过远程调试运行生产机器，并手动逐步调试它们？构建适当的脚本与编写程序相同。您遇到的所有问题都表明需要注意和检查的事情。

如果出现问题，则应执行适当的回滚过程，并向您发送消息。发生的所有事情都可以记录下来，以便以后使用。您可以对脚本进行版本控制，并设置测试用例。

但是，如果您手动运行命令，则没有任何这些优点。相反，您有一系列缺点。

• 您的日志不好，shell历史记录也不重要
• 没有人知道该怎么做
• 错过步骤
• 仅在某些时候进行检查
• 有些部署项目可能会遗漏，我之前已经做过
• 需要更长的时间
• 您可能会在此过程中被打扰

正确的脚本应该几乎与在外壳上键入所有内容的脚本相同。这是我们拥有bash脚本的原因之一。如果您相信自己所做的事情，为什么不能记录所有内容并加以加强？由于计算机可以执行更好的检查，更快的检查和更多的检查。

我可以理解在产品环境中尝试一些新事物会有些紧张。作为警惕潜在的灾难是一件好事^TM。

自动化脚本也是Good Thing ^TM，只要您仔细地进行操作，就应该能够最大程度地减少危险并降低恐惧感。所以我的建议是这样；

• 准备（在集成环境中进行实践）检查清单/测试集，以便您快速找出它是否有效以及是否出了问题。详细日志记录可能对此有所帮助。
• 备份所有内容。准备并练习手动回滚，以便在出现严重错误时可以恢复。
• 在正式生产之前，请尽可能多地测试。听起来好像是集成环境中的一个好方法。
• 第一次尝试时，请在低调，低影响的更改上进行。诸如次要升级或补丁之类的东西。这样做的目的是在发生错误时将后果降到最低。不要为首次运行选择高调的重大升级（CEO和所有竞争对手都在注视）。

一旦成功运行了几次，您的信心就会增强，很快您就会想知道如何管理手动部署。

这是反对将人工部署到生产环境的最大论点：您是人类，会犯错误。毫无疑问，有时您会忘记做会引起悲伤的事情。编写良好的自动化部署不会有相同的趋势。的确，您仍然可以进行混乱的生产部署，但这是因为您的自动部署中存在需要解决的错误。

以我的经验，自动部署到生产中的好处是巨大的。最大的好处是，您可以在周末玩得开心，而不是尝试通过不会合作的手动部署过程。

也就是说，这是一些自动化生产部署的关键指标：

• 不要一次全部做！开始慢慢地编写您的自动化部署。首先设置一个单独的非生产环境，然后尝试在那里自动化部署。建立对自动部署的信心后，您就可以开始考虑进行生产部署了
• 开始非常频繁地发布和部署！如果您没有等待4个月的代码发布的时间，则进行自动化部署会容易得多。每周多次发布小功能和错误修复。这种发布方式的好处不可低估！
• 依靠自动化测试使您有信心您的生产环境将正常工作。同样，这需要时间来建立，但是非常重要。自动化测试总是比手动验收测试更好。当然，手动验收测试很好，但是自动化测试可以帮助您知道是否应该将其部署到生产中。它们是实现整个自动化，连续交付过程的关键。如果您的测试没有通过，您就知道不会部署到生产中。

在实时服务器上运行脚本。它会起作用，并且在您几次看到它都可以正常工作之后，您将对其充满信心。

严重的是，比部署脚本更容易出错。

计算机不会犯错误，人们会犯错误。

一次编写脚本并进行彻底检查，然后逐行进行检查。从那时起，您可以确保每次部署都可以使用。

用手做，您肯定会犯错误。也许您写下了您必须做的所有事情，但这很容易出错。您必须复制除web.config文件之外的所有文件吗？您可以打赌有一天您会覆盖它。脚本永远不会犯此错误。

如何在不感到极端焦虑的情况下自动化生产部署？

自动化生产部署时会遇到的极端焦虑很可能是基于以下两个信念：

1. 一天或另一天，某个部署步骤将失败，您或另一个人可以从故障中快速恢复，而自动化脚本可能会忽略它。

2. 生产中被忽视的失败会产生严重后果。

除了避免失败之外，几乎没有人可以做有关2的事情。因此，让我们关注1。

一种对现有产品稍作改进的廉价解决方案是使用半自动部署过程，在安装的每个步骤结束时等待验证。使用半自动解决方案，您将享受到全自动解决方案的好处，例如一致性和可重复性，同时您仍将有机会监视进度并从错误中恢复（如您目前所习惯的那样）。

半自动化脚本及其生物群落（回归测试等）也可以用作您收集有关安装过程中发生的故障以及从故障中恢复的知识的工具。

我喜欢的是，您可以在阶段或QA上测试部署，并且知道在产品上运行部署时，会发生完全相同的步骤。

手动执行操作时，忘记某个步骤或使它们混乱会更容易。

...由于硬件和资源的限制，我们的集成环境不是像生产环境那样的2服务器负载平衡环境。尽管其他所有条件都相同，但这将是我们的集成和生产环境之间的唯一区别（尽管很大！）

鉴于以上所述，我可能会和您一样着急。

我曾经对部署到SLB的自动化脚本进行过检查和测试，我的感觉是，如果没有在负载平衡设置下进行预测试，我会希望手动执行操作。

除了类似于产品的测试设置外，另一个让我省心的重要因素是，产品的部署是由开发人员的其他团队完成的，他们的工作仅是维护生产环境。

• 在其中一个项目中，我以开发团队代表的身份协助他们进行部署。在部署之前，他们正在查看我的说明，而在部署期间，我正坐在网上准备咨询发生的问题。那时，我学会了欣赏这种分离。
   
  并不是说它们更快（为什么？为什么我比他们更频繁地测试部署5到10倍）。最大的区别在于焦点。我的意思是，我的头总是被“主要”内容所累-编码，调试，新功能-太多的干扰无法正确地专注于部署。与此相反，他们的主要工作只是生产维护，他们专注于此。
   
  令人惊讶的是，专注时大脑有多好。这些家伙，他们专心得多，他们犯的错误比我少得多。他们只是比我更了解这些东西。他们甚至教会了我一两件事，使我自己的测试部署变得更加容易。

构建一个部署脚本，您可以使用该脚本将代码移动到任何环境中。我们使用完全相同的部署过程将代码移至开发，质量保证，登台以及最终生产。由于我们每天要进行多次开发以进行部署，并且每天都要进行质量检查，因此我们已经确信部署脚本是正确的。基本上，通过经常使用它来进行测试。

1. 简化。您的更改过程应该是rsync文件，运行SQL脚本，仅此而已。
2. 自动化。
3. 测试。

自动化的原因是要获得可测试，可重复的东西，并且您可以信任它可以在每种预期情况下正常工作。

对于任何上下文中的任何更改，您仍然需要制定退出计划，并且该计划也应该是自动化的。

如果环境真的很敏感，您仍将希望观察该过程的发生，但是由于它无法复制，因此永远不要手动进行。

完全有可能使用自动化脚本来部署到生产环境。但是，要可靠地这样做，您需要能够做几件事。

1. 可靠地回滚到以前的版本。
2. 获得有关部署已成功应用并且正在响应有效流量的肯定确认。
3. 具有可比较的开发和质量检查环境，它们也使用相同的脚本。

脚本有一些优点，例如，它们永远不会错过一个命令，因为它凌晨2点而且很累。

但是，脚本可能并且仍然会失败。有时，失败是由于脚本的设计引起的，但也可能是由于网络或电源故障，文件系统损坏，内存不足而引起的。

因此，在脚本运行之后，必须遵循定义的测试阶段，以在启用实时流量之前验证新部署是否已启动，正在运行并处理请求，这一点很重要。

1. 如果出现问题，请在第一次使用更大的窗口进行部署

2. 将部署过程分为两部分。一种。备份（手动）-如果在部署过程中出现任何问题，这将使您充满信心

   b。部署（自动）

一旦您能够自信地进行部署。您也可以自动执行备份过程。