持续集成与持续交付（1）——基本原理

传统开发

传统开发方式的拥护者和敏捷开发方式的拥护者看待软件开发的世界观是不同的。
在传统开发的眼里，软件开发过程是确定的、可测的，只要在一开始努力收集到需要的信息并制定好计划，然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好，没收集到必要的信息，计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程，文档，试图让每一步都做到万无一失。

敏捷开发

而在敏捷的眼里世界可不是这样的，敏捷认为在软件开发中，世界是变化的，有很多不确定首先不论哪种开发方式，不过不管什么开发方式前期还是要做足充分的调研和分析，收集足够多的信息。但是我们不是先知，没人能确保自己的预测足够准确，也没人能保证能收集到所有有用的信息。但是可以肯定的是随着开发的进行，我们对会对正在做的东西的认识越来越深刻。因而做一段时间后常常有发现需求有调整，或发现之前的想法不对。另一方面，世界本来就是在快速变化中，尤其是互联网，所以我们也不得不适应这个环境。所以为了适应这个市场的变化，我们要采用敏捷开发。

总结

在传统开发中要做好一个产品，大部分精力都要花在前期

更多调研
更多信息
更多文档
缺点

始终走在市场后面，无法紧跟潮流，做出的产品容易被淘汰。

敏捷开发核心
拥抱变化
快速迭代

持续集成CI（Continuous Integration）

持续集成（Continuous Integration）简称CI，持续集成强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续集成过程中很重视自动化测试验证结果，对可能出现的一些问题进行预警，以保障最终合并的代码没有问题

持续交付CD（Continuous Delivery）

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。

这里强调的是

手动部署
有部署的能力，但不一定部署

持续部署（Continuous Deployment）

基本概念

持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。

这里强调

持续部署是自动的
持续部署是持续交付的最高阶段

持续交付（Continuous delivery）与持续部署的关系

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

持续交付表示的是一种能力
而持续部署则是一种方式
具体实现
整体而言，Jenkins 过去一直是大部分公司的选择，但这个现象正在发生改变，随着公有云服务、Docker，SaaS 的普及，越来越多的企业开始选择在线托管型持续集成系统。

总结

「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。