标签（空格分隔）： 翻译
原文地址： Continuous Delivery - Automating the Release Process
对于很多开发者来说，发布版本的那天都会陷入巨大的压力。发布过程中总是有些风险，比如出现某些莫名其妙的问题，或者是产品里又被发现了某个bug。在我上一家公司，我们采取的是手动发布版本，过程基本都是人工去做的，因此，特别容易出现问题。在发布当天，DevOps（译者：看百度百科是怎么描述 DevOps 的职责）部门会加载二进制的运行文件，然后做用户验收测试。如果所有的测试都成功，软件就会复制到服务器上，进行冒烟测，一般来说，还会进行一次前一版本的用户验收测试。下面列举出通常都会遇到的问题：
简单的说，手动和没有固定的发布流程绝不是好的选择，发布那天总会承受很大的压力。在我们的案子里，如果发布不是很频繁，团队也还不够成熟时，这样的方式是可以接受的。为了改进和自动化发布流程，有一种软件工程的方法叫持续交付。
持续交付使得发布新的功能更快更稳定。同时可以让开发者更及时的收到反馈 。我们开发一套软件，可以在任何时候自动安全的部署到产品上。这就确保了发布里的每一次改动，都会发布到类似真实产品环境上，并且可以运行大量的自动化测试。按照 Martin Fowler 的理论，如果你做到以下的了，那么就称得上是持续交付：
持续交付，是持续集成（CI）的一个重要的先决条件。持续集成要求任何新的改动都可以快速的集成到主分支上， 整个项目一直都处于开发状态中 。通常来说，它是这么工作的：一旦有改动发布到github上，就会重新编译部署。整个应用都会按照所要求的配置去编译， 一系列单元以及集成测试都会重新运行 。如果测试失败，团队会停止工作直到修复了问题。没有了持续集成，集成很容易就变成梦魇。当我启动一个新的项目的时候，如何持续集成会是我考虑的首要事情。
我看到过很多的案例，整个团队都不想关注那些出了问题的编译。这通常都发生在持续集成过程已经变成了巨大多毛的怪兽的时候。这也有违持续集成的首要目标： 出了问题的版本决不能被忽视，团队的首要任务就应该是去修它们 。为了确保这件事，持续集成的过程应该尽可能的短，好使，简单。如果测试的运行会占用过多的时间，不可靠也不能帮助定位问题，那么团队就会不去尝试修改问题版本，甚至互相推诿责任，说是别的团队弄坏了版本。
持续集成主要是在关注开发团队。 持续集成里也可能会有手动去发布版本的过程 。在我们做过的案例里，也有手动的拷贝二进制文件和对应的配置文件到演示和生产环境里的。与之相反的是，持续交付会将整个发布流程自动化。为了达到这一目标，我们使用了一条流水线，这条流水线有非常清晰的阶段和对应的过程。
一条持续交付的流水线是让你的新版本发布出去的流程的集中体现。按照 Martin Fowler的理论：
一个典型的持续交付过程如下：
决定这条持续交付流水线成功与否的部分就是验收测试，验收测试位于这条流水线的较靠后的阶段，也就是“更多靠摸索”的阶段。他们确定软件能满足用户的需求和指标。验收测试不应暴露内部系统的细节，应该就像对待黑盒一样对待。我们的验收测试会由模拟一个真正的用户会输入的内容，接受并验证系统的输出并验证这些输出是否符合预期。
在持续交付的流水线上，从一个阶段转到下一个阶段可以使手动，也可以是自动的。手动并不意味着把内容拷贝复制到下一个流程中。它只是意味着，操作人员需要标记一下，表示现在的阶段已经完成，可以转交到下一个阶段了，而这个过程通常会需要手动的按一下按钮。
持续交付的流水线能在确定了交付流程之后被定型下来。没有所谓的标准答案：一个流程总会和另一个看上不太一样。举个例子，在一个有很多独立组件的SOA项目里，我们觉得一个为所有的组件制定一个流程是最好的方案。而另一个项目要求给每一个组件都制定独立的流程，而整合到一起之后的流程，可以参考下图。
实现一个好的持续交付流程是一个让人沮丧的任务，但是一旦完成好了，会产生巨大的好处。在我看来，最好的方式就是仔细研究你的部署过程，理解所有的依赖关系，从一些比较小而且简单的地方开始入手。
持续交付中，总需要有人最终去确定把产品部署到生产环境中。一个典型就是，发布的软件发生了一些变动之后或者是在固定的日子。
而持续部署比持续交付则更进一步：每一次改变，只要通过了自动化测试就会自动的部署到生产环境。持续部署可能不适用于所有的项目，即使理论上听上去很棒，但是我可以肯定，我目前还没有在商业项目里尝试过这种方式。Yassal Sundman的博客上有一副图，是比较持续交付和持续部署的过程：
对于持续交付的工具我没有特别的个人偏好。最近我开始在使用AWS的CodePipeline（和AWS的CodeDeply类似）去自动化AWS云上的交付流程，我对此这个工具非常满意。