我目前在一家通过github部署的公司工作。但是，我们必须登录所有3台服务器才能使用shell脚本手动更新它们。在与CTO交谈时，他明确表示自动部署对他来说就像伏都教一样。这是可以理解的。我们有4个不同国家的开发人员远程工作。如果有人不小心推到错误的分支机构，我们可能会遇到停机时间，而且我们的服务不能超过10分钟。由于我们的所有开发人员都在不同的时区，我们的CTO直到第二天早上都不知道，因为时差很大，我们很难与遇到问题的开发人员会面。
在处理我的个人项目时，我认为使用自动部署可能符合我的最佳利益，但我的项目仍然是关键任务，我希望尽可能地减少停机时间和人为错误 。手动部署的问题是我无法在合理的时间内通过SSH手动部署多达20台服务器。当我考虑自动缩放时，问题会持续存在。我需要从图像中启动一个新服务器并部署到它。
我的服务是在Node.js Express框架上开发的。这些环境在部署和引导实用程序方面非常丰富。我的项目在部署时使用npm的package.json来uglify我的脚本，并使用forever-monitor作为守护程序运行我的服务。我也在考虑grunt.js进一步为生产和测试环境引导我的环境。
到目前为止我已经考虑过了：
我不熟悉像Docker这样的技术，但是我很感兴趣，我肯定会给那些给我一个很好的描述的人一点，说明为什么我应该或不应该使用Docker，因为我非常对它的使用感兴趣。其他方法也很受欢迎。
在任务关键环境中，停机会使您的业务处于暂停状态，更糟糕的是，有一群终端用户点击了刷新按钮。如果有人将那些不构建的东西推送到生产分支并且自动部署，那么我正在看一个非常混乱的情况。
我喜欢自动部署的优雅，但风险让我持怀疑态度。我非常赞成让自己尽可能高效。所以我正在寻找一种方法，以非常有效的方式轻松部署到许多服务器。
向我解释如何降低自动部署的风险，或向我解释一个更适合我项目的替代方案。请随意在评论中询问任何遗漏的细节。
答案 0 :(得分：0)
这里没有简单的答案。我提供了一套由Etsy的Mike Brittain发布的幻灯片，这是一家实施持续部署的公司：
http://www.slideshare.net/mikebrittain/mbrittain-continuous-deploymentalm3public
精选亮点：
希望这有帮助