什么是持续部署？

Thousands of years ago, back before people lived in houses and when dinosaurs still ruled the earth, software development took a long time. First, you did the design (figuring out what you want to do and how you’re going to do it). Then you wrote the code. Then you did testing (the stage of the project where people pretend to look over what you created but really don’t pay attention). This lead to changes, sometimes drastic changes, in what you did. Finally, you moved everything to production and went live (also known as final testing because now people are forced to pay attention).

几千年前，在人们居住在房屋中以及恐龙仍然统治地球之前，软件开发花费了很长时间。 首先，您进行了设计(弄清楚了您想做什么以及将如何做)。 然后，您编写了代码。 然后，您进行了测试(项目阶段，人们假装查看您创建的内容，但实际上并没有注意)。 这会导致您所做的更改，有时甚至发生剧烈的更改。 最后，您将所有内容都投入生产并投入使用(也称为最终测试，因为现在人们不得不注意)。

Then Agile came along. And Scrum. And Lean. And the idea that maybe it would be better if the whole cycle (design, coding, and testing) was compressed so that, rather than taking months to get something into the users’ hands, it would take maybe just weeks.

然后敏捷来了。 和Scrum。 和精益。 而且，如果压缩整个周期(设计，编码和测试)可能会更好，这样一来，可能要花费数周的时间，而不是花数月时间才能将某些东西交到用户手中。

The final move in that direction (so far) was broadly labeled Extreme Programming, where all coding had to either be done at high altitudes or else on a skate board. As part of that, we added the deployment phase to the quick turn around cycle. And this is where Continuous Deployment fits in. Essentially the idea behind Continuous Deployment is that functionality is moved to production as soon as it’s coded and tested so it can be used (that is, really tested).

迄今为止，朝着这个方向的最后一步被广泛地标记为极限编程，其中所有编码都必须在高海拔或在滑板上进行。 作为其中的一部分，我们将部署阶段添加到了快速周转周期中。 这就是Continuous Deployment的适用范围。本质上，Continuous Deployment的思想是，一旦对功能进行编码和测试，就可以将其功能投入生产，以便可以使用(即经过实际测试)。

各种连续选项 (The Various Continuous Options)

If you think your life is complex enough, then you might want to pretend that this particular section doesn’t exist. There are a number of similar and yet different terms (especially if you talk to the experts) that describe all of this. Break out the Dramamine and hang on.

如果您认为自己的生活足够复杂，那么您可能要假装此特定部分不存在。 有许多相似但又不同的术语(特别是与专家交谈时)描述了所有这一切。 打破剧情并坚持下去。

If you Google “Continuous Deployment” you will see many references to Continuous Integration and Continuous Delivery. They sound the same but, if you listen to the experts, they’re really very different (which means that they’re really pretty much the same).

如果您使用Google“持续部署”，则会看到许多关于持续集成和持续交付的参考。 它们听起来是一样的，但是，如果您听专家的话，它们实际上是非常不同的(这意味着它们确实非常相似)。

Continuous Integration really refers to the front-end of the process; the building, integrating, and testing of code within a development environment.

持续集成实际上是指流程的前端。 在开发环境中构建，集成和测试代码。

Continuous Deployment is described as something where every change that goes through the deployment pipeline is automatically loaded into production.

连续部署被描述为将通过部署管道进行的每个更改自动加载到生产中的一种方式。

Continuous Delivery, on the other hand, is where everything goes through the pipeline but you choose when that happens, rather than all the time as with Continuous Deployment.

另一方面，连续交付是所有事情都在管道中进行的地方，但是您可以选择何时进行，而不是像持续部署那样始终选择。

持续部署的优势 (Advantages of Continuous Deployment)

The first advantage of Continuous Deployment is that its continuation of Agile’s focus on small scale tasks as a unit helps to reduce the complexity of the deployment effort. That is, it’s easier to move one module and two files than 50 modules and 100 files, and that hopefully leads to fewer deployment mishaps.

持续部署的第一个优点是，它继续保持对小规模任务的敏捷性，这有助于减少部署工作的复杂性。 也就是说，与50个模块和100个文件相比，移动一个模块和两个文件要容易得多，并且有望减少部署的麻烦。

The second advantage is that it makes it less likely that you and someone else on your team will get your tasks tangled up. This is particularly true if you are in a large organization with many developers but you are not in a situation where a given developer has complete and sole control of a given application. The shorter the time that a module is checked out and is worked on before it’s pushed out to production, the less likely that two developers will check out and separately update the same module.

第二个优点是，它使您和团队中的其他人很难完成任务。 如果您所在的组织中有许多开发人员，而您却不在给定开发人员完全控制给定应用程序的情况下，则尤其如此。 在将模块推出生产之前，检出和处理该模块的时间越短，两个开发人员检出并分别更新同一模块的可能性就越小。

持续部署的缺点？ (Disadvantages of Continuous Deployment?)

As we well know, every rose has it’s thorns, right? So there must be some disadvantages to Continuous deployment as well.

众所周知，每朵玫瑰都有刺，对吗？ 因此，连续部署也必须有一些缺点。

To the uninitiated (this includes every manager I have ever worked for), Continuous Deployment is code for “poor quality code thrown out there to let the user swim for his life”. But the truth is, Continuous Deployment means just the opposite. The basic assumption is that the code that you do deploy quickly will be clean. To do that, a focused and disciplined approach is required. Continuous Deployment is not for hackers or the insincere.

对于刚起步的人(包括我曾经工作过的每位经理)，持续部署都是“为那里的用户抛出质量差的代码，使用户终其一生”的代码。 但事实是，持续部署的含义恰恰相反。 基本假设是，您快速部署的代码将是干净的。 为此，需要有针对性和纪律性的方法。 持续部署不适合黑客或不真诚的人。

Another thing that some people say is that while it might be a nice thought, Continuous Deployment is just too complex to do. And there is some truth to that; there has to be some complexity involved if you’re moving new code to production multiple times per day automatically and without mishap. But I don’t see anybody complaining about the complexity of the new BMW when the engine cuts out when it’s stopped at a red-light and then comes back on again automatically, so we should all be able to agree that complexity is okay as long as it works and leads to a good outcome.

有人说的另一件事是，尽管可能是个不错的主意，但是连续部署实在太复杂了。 这是有道理的； 如果您要每天自动将新代码多次移至生产环境中，而不会遇到麻烦，则必须涉及一些复杂性。 但是我看不到有人抱怨新宝马的复杂性，因为当红灯停止时，发动机熄火后又自动重新启动，因此我们都应该同意，只要有时间，复杂性就可以了因为它有效并导致了良好的结果。

持续部署入门 (Getting Started with Continuous Deployment)

So what do you need to do Continuous Deployment? Other than the simple faith of a child, that is. Unfortunately, Continuous Deployment is not just an idea that you can casually implement. You need some solid procedures and software behind it.

那么，您需要做什么进行持续部署？ 就是说，除了孩子的简单信仰。 不幸的是，持续部署不仅仅是可以随便实现的想法。 您需要背后的一些可靠程序和软件。

First, you need an integration environment. This is a server that replicates the production environment, giving you something that you can test in and with.

首先，您需要一个集成环境。 这是一台复制生产环境的服务器，为您提供可以在其中进行测试的东西。

Second, you need a full set of test scripts (this is the sticking point with many people). We code up a new script, run them through a couple of obvious things, and then we’re ready to go. Who keeps track of tests? But that’s too dangerous when talking about Continuous Deployment. You need to have a complete set of test scripts designed to find any and all errors. If you don’t have this, don’t even bother.

其次，您需要一整套测试脚本(这是很多人的症结所在)。 我们编写了一个新脚本，通过一些显而易见的事情来运行它们，然后我们就可以开始了。 谁跟踪测试？ 但这在谈论持续部署时太危险了。 您需要具有一套完整的测试脚本，这些脚本旨在查找所有错误。 如果您没有这个，就不用打扰。

Third, you need a piece of software generally referred to as “build software” that automates the process of putting the new code in with the existing code, running through the test scripts, notifying you of any problems, and then, if all goes well, pushing the new code into your production and test environments. Examples of this include Cruise Control, Jenkins, BuildBot, Bamboo, etc.

第三，您需要一个通常称为“构建软件”的软件，该软件可以自动执行以下步骤：将新代码与现有代码一起放入，运行测试脚本，并通知您所有问题，然后一切顺利，将新代码推送到您的生产和测试环境中。 这样的示例包括Cruise Control，Jenkins，BuildBot，Bamboo等。

结论 (Conclusion)

I don’t want anyone to be fooled. Continuous anything is not simple to implement. It requires a real commitment. It requires exhaustive test scripts. It requires sophisticated software to make it automatic (and thus practical). But for people in a multi-developer environment, one where responsiveness to user demands is important, where speed and reliability of changes is important – Continuous Deployment just might become your new best friend.

我不希望任何人被愚弄。 连续的任何事情都不容易实现。 这需要真正的承诺。 它需要详尽的测试脚本。 它需要复杂的软件才能使其自动化(因此实用)。 但是对于在多开发人员环境中的人员来说，对用户需求的响应能力很重要，而更改的速度和可靠性很重要–持续部署可能会成为您的新朋友。

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/whats-continuous-deployment/