减轻自动部署的风险 [英] Mitigating the risks of auto-deployment

问题描述

我目前在一家通过github进行部署的公司工作。但是，我们必须登录所有3台服务器，以使用Shell脚本手动更新它们。在与CTO交谈时，他非常清楚，自动部署对他来说就像是伏都教。这是可以理解的。我们在4个不同的国家/地区都有开发人员进行远程工作。如果有人不小心将其推到错误的分支机构，我们可能会遇到停机时间，而凭借我们的服务，我们停机的时间不能超过10分钟。由于我们所有的开发人员都处在不同的时区，因此我们的CTO直到第二天早上才知道，而且由于时差巨大，我们很难与遇到问题的开发人员会面。

I currently work for a company that deploys through github. However, we have to log in to all 3 servers to update them manually with a shell script. When talking to the CTO he made it very clear that auto-deployment is like voodoo to him. Which is understandable. We have developers in 4 different countries working remotely. If someone where to accidentally push to the wrong branch we could experience downtime, and with our service we cannot be down for more than 10 minutes. And with all of our developers in different timezones, our CTO wouldn't know till the next morning and we'd have trouble meeting with the developers who had the issue because of vast time differences.

在处理个人项目时，我认为使用自动部署可能最符合我的利益。 ，但我的项目仍然是关键任务，我想尽可能地减少停机时间和人为错误 。手动部署的问题是，我根本无法在合理的时间内通过SSH在多达20台服务器上手动部署。当我考虑自动缩放时，该问题将持续存在。我需要从映像启动新服务器并将其部署。

While working on my personal project I decided that it may be in my best interest to use auto-deployment, but still my project is mission critical and I'd like to mitigate downtime and human error as much as possible. The problem with manual deployment is that I simply cannot manually deploy on up to 20 servers via SSH in a reasonable amount of time. The problem perpetuates when I consider auto-scaling. I'd need to spin up a new server from an image and deploy to it.

我的服务是在Node.js Express框架上开发的。这些环境在部署和引导实用程序中非常丰富。我的项目使用npm的package.json在部署时 uglify 我的脚本，还使用 forever-monitor 。我还考虑使用 grunt.js 进一步为生产和测试环境引导我的环境。

My service is developed on the Node.js Express framework. These environments are very rich in deployment and bootstraping utilities. My project uses npm's package.json to uglify my scripts on deploy, and also runs my service as a daemon using forever-monitor. I'm also considering grunt.js to further bootstrap my environments for both production and testing environments.

到目前为止，我已经考虑过：

I've considered so far:

• 使用git自动部署，使用webhooks


• 通过shell通过git手动部署


• 通过shell通过npm进行部署


• Docker

• Auto-deploy with git, using webhooks
• Deploying manually with git via shell
• Deploying with npm via shell
• Docker

我并不精通Docker等技术，但我很感兴趣，我肯定会给给我一个很好描述的人一个分数关于为什么我应该使用或不应该使用Docker的信息，因为我对它的使用非常感兴趣。欢迎使用其他方法。

I'm not well versed in technologies like Docker, but I'm interested and I'd definitely give points to whoever gave me a good description as to why I should or shouldn't use Docker, because I'm very interested in its use. Other methods are welcome.

在关键任务环境停机期间可能会使您的业务暂停，更糟糕的是，有大量的最终用户点击了刷新按钮。如果有人将无法构建的东西推送到生产分支并且已经自动部署，那么我正在看一个非常混乱的情况。

In a mission critical environment downtime can put your business on hold, and to make matters worse there's a fleet of end users hitting the refresh button. If someone pushes something that's not build passing to the production branch and that's auto-deployed, then I'm looking at a very messy situation.

我喜欢汽车的优雅部署，但是风险使我感到怀疑。我非常赞成让自己尽可能多产。因此，我正在寻找一种轻松且以非常有效的方式部署到许多服务器的方法。

I love the elegance of auto-deployment, but the risks make me skeptical. I'm very much in favor of making myself as productive as possible. So I'm looking for a way to deploy to many servers with ease, and in very efficient manner.

向我解释如何减轻自动部署的风险，或向我解释更适合我的项目的替代方法。随时询问评论中是否缺少任何细节。

Explain to me how to mitigate the risks of auto-deployment, or explain to me an alternative which is better suited to my project. Feel free to ask for any missing details in the comments.

推荐答案

在这里没有简单的答案。我提供了由Etsy公司的Mike Brittain发布的一组幻灯片，该公司从事持续部署工作：

No simple answer here. I offer a set of slides published by Mike Brittain from Etsy, a company that practices continuous deployment:

http://www.slideshare.net/mikebrittain/mbrittain-continuous-deploymentalm3public

选定的重点：

• 频繁且小批量部署


• 使用config / feature标志来控制系统行为和暗发布主要功能


• 代码检查生产分支的所有更改


• 投资监控并改善反馈环


• 分别对应用程序管理服务，并注意运行时版本和向后兼容的更改。

• Deploy frequently and in small batches
• Use config/feature flags to control system behaviour and "dark release" major features
• Code review all changes to the production branch
• Invest in monitoring and improve the feedback loop
• Manage "services" separately to the "application" and be mindful of run-time version and backwardly compatible changes.

希望这会有所帮助

这篇关于减轻自动部署的风险的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！