为什么持续集成和部署在开发中非常重要？
让重复的事情自动化。
如果运用得当，CI/CD 将会是一个很好的工具，帮助团队提效。你要相信，肯定没有人愿意花几个小时时间，去“盯”部署脚本执行的结果，还要手动测试来确认系统是否能正常运行。
以下为译文：
写在前面
这是我「主流软件开发实践」系列文章中的第一部分，在本系列文章中，我计划包含软件工程师通过提升开发流程和实践来改善软件开发的一系列方法。我曾在 ThoughtWorks 担任软件顾问，现在我在德国一家大型的零售公司工作，这些方法都是我在职业生涯中学习并实践验证过的。
我曾经参与过一个客户的云迁移项目。那是我第一天去办公室办公，经过了一天的工作，就在快下班的时候，一位高级工程师邀请我与他一起“盯”项目部署情况，这让我变得非常兴奋，因为在之前，我从来没有干过“盯”项目部署的事情，我很期待能在此次的“盯”中，学习到之前不会的“知识”。
这还真是一个令人“激动”的过程，“盯”部署真是最坏的决定。
这家公司，我暂且叫他 A 公司好了。他们公司系统总共有16个部署实例，在他们的数据中心，不同的 Linux 机器上，分别跑着这些实例，他们还使用不同的名字，来区分不同机器上的实例。那天的部署，我看到他们使用自己的电脑，分别远程连接到每一台服务器上，然后执行一个之前写好了的部署脚本。当部署脚本执行完毕，他们还需要手动测试，来确保服务器已经正常地运行起来了。我们花费了三个小时的时间，来“盯”整个部署过程。
值得庆幸的是，除了上面我所说的这哥们儿，他们公司还有一个工程师知道如何在服务器上进行部署。但是，他们情况也不容乐观，不能同时休假，而且每当其中一个人生病，不能参与工作时，另一个人就要独自进行部署，并承担起工作中所有的事情。现在，他们的部署每两周执行一次。
晚上，我下班回到家，但今天的事让我久久不能入睡。
在我多年的工作中，我最喜欢做的一件事情就是：让重复的事情自动化。我知道，很多程序员都说过这个话。我一直把“任何事情不要做两遍”这句话当做我的座右铭。
对于任何一个团队来说，系统自动化部署都是一件非常重要的事情，这也是我在 A 公司所做的第一件事，使用构建管道来实现持续集成与持续交付。持续集成流程如下：
持续集成示例图
持续集成
在业界，我们通常将它称之为 CI ，这是一种开发、部署的实践。开发人员每天都将自己的更改推送到主分之中进行集成，通常情况下，这样的操作每天都会发生很多次。从更高的视角来看，CI 能使开发者更快的发现模块或功能中的错误。持续集成的整个流程很简单：
开发者将代码提交到项目主分支；
CI 服务器检测到更改并将最新代码拉下来；
CI 服务器编译更改后的代码，并给他们打个标签；
CI 服务器执行所有的单元测试、集成测试、端到端的测试；
如果上述任何阶段，出现任何问题（包括测试用例失败），整个 CI 流程将会被停止，并且将错误信息发送给开发人员。
无论提交的大小，CI 能让整个团队看到每一个提交对整个项目的影响。当流程中出现问题的时候，通过 CI，可以准确地知道问题是由哪个提交造成的，也有可能从错误信息中看到是因为哪一行代码引起的。
DevOps 中建议开发者，每一个代码提交，文件变更都尽可能地小。持续集成的最佳实践告诉我们，最好也按照 DevOps 中的建议做。当然，我们也需要确保，所有运行环境都要尽可能保持一致，不论是在开发环境、测试环境、集成环境、还是生产环境。
GoCD 的流程
持续交付
持续交互在业界被简称为 CD ，是指在自动完成所有的自动化测试代码过后，将通过的代码进行直接部署。
从本质上来讲，这是软件发布的最佳实践。—— Jez Humble（译者注：Jez Humble，被誉为「持续交付之父」，《DevOps 实践指南》、《精益企业》、《持续交付》作者。）
持续交互还应该包含以下几点：
作为整个构建流程的一部分，你需要在所有的测试通过过后，自动创建一个版本，并使用脚本，将它自动部署到你所有的环境中去（测试环境、集成环境、生产环境等）。
作为整个流程的最后一个步骤，你还需要运行冒烟测试，来确保你所部署的服务正在顺利的运行。
设置监控报警，当出现问题是要第一时间通知开发者。
应该提供功能切换的功能，隐藏代码的具体实现细节。
在部署过程中，所有的修改都是单独提交的，因此由部署带来的风险和 Bug 也会相对较少。这意味着，企业能够根据需求，更加快速地开发并部署代码。如果能将 CD 与容器化技术（如 Docker、k8s）配合使用，在云平台上，甚至可以实现不停机部署，这样开发团队就可以在任何时间进行代码部署。
为什么非常重要？
正如 《Accelerate》一书中所说，软件团队的性能和效率可以通过四个指标来检查。而良好的 CI / CD 的实践可以大大改善四个指标的得分。
交付时间：
CI / CD 可以让开发人员编写的代码直接部署到生产环境中。如果一个团队有良好的 CI / CD 的流程时，可能只需要几个小时甚至是几分钟时间就能完成新需求上线。
部署频率：
如果能够快速部署，小范围部署，那么团队可以频繁地进行部署，特别是那些“无关紧要”的部署。还记得我前面说到的 A 公司吗？想像一下，如果只需要点一个按钮就能进行部署，那他们的团队是不是都很愿意将代码部署上去？Amazon 曾公布数据表示，在他们全球所有的团队中，平均每 11s 就会部署一次。
平均故障恢复耗时：
举个例子，如团队中的某一个部署导致整个系统崩溃，有可能让整个系统停机好几个小时。那如果这个团队有良好的 CI / CD 的实践，那他们可以很准确地知道是由于哪个更改造成，知道是由哪个产品线更新引起的。或许 15 分钟后，就能够开发出修复程序并将其重新部署到生产环境中。
变更失败率：
如果使用了 CI ，那么所有的修改都会在你的 CI 服务器进行集成并运行所有的单元测试，这些修改也会在与用户环境非常接近的环境中进行运行，当这些变更呈现在用户面前时，都已经是经过了大量的测试验证过的版本，几乎不会出现任何隐藏的 Bug。
注意事项
当团队试图尝试使用 CI / CD 时，开发者在开发中，仍需要记住以下几个事情：
阻塞整个 CI / CD 流程的 Bug 需要第一优先级处理；
开发者应该尽可能避免大变更提交，应该尽可能拆分成多个提交；
开发者提交代码之前应该先跑一下测试代码，保证当前修改不会中断整个编译流程；
下班之前，不允许存在无法编译的问题。
如果运用得当，CI/CD 将会是一个很好的工具，帮助团队提效。你要相信，肯定没有人愿意花几个小时时间，去“盯”部署脚本执行的结果，还要手动测试来确认系统是否能正常运行。他们更希望，每天都只需要简单地将代码推送到代码库，剩下的事情就系统自动去做，当出现错误时，也能收到提醒。
开发者应该去解决问题，而不是去做那些电脑就可以完成的事。
你可以选择使用任何一个流行的 CI 系统（Concourse、Jenkins、GoCD、Circle-CI 等等），来帮助你完成很多开发上的事情，让开发者在解决问题的同时，也能保证系统的稳定性。
正说 Nike 所说， CI / CD 是主流软件开发实践中可以采取的最直接一步，你只需要：
JUST DO IT.
系列阅读：《被高估了的测试驱动开发？》
英文：Here’s Why Continuous Integration and Deployment is so Important to the Software Development Process
链接：https://levelup.gitconnected.com/heres-why-continuous-integration-and-deployment-is-so-important-to-the-software-development-c0caeead5881
作者：Tylor Borgeson，全栈软件开发者，对机器学习、AI、基础架构、DevOps 及敏捷等拥有强烈兴趣。
译者：罗昭成，Android 开发者。
《原力计划【第二季】- 学习力挑战》
正式开始
即日起至 3月21日
千万流量支持原创作者
更有专属【勋章】等你来挑战
☞狂赚 1200 亿，差点收购苹果，影响千万程序员，那个叫做太阳的公司却陨落了！
☞两成开发者月薪超 1.7 万、算法工程师最紧缺！| 中国开发者年度报告