What-is-continuous-integration-part-1
持续集成CI，在一般软件开发中，每个人在完成项目工作后开始完成整合工作。整合一般需要数周或数月时间，整合过程是非常痛苦的。持续集成是一种在早期开发阶段，每天数次的合并代码到主干，持续的进行构建、测试和集成代码。
持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
持续集成的目的，可以更高效率的快速迭代软件产品，同时还能保证高质量。它可以保障，我们把代码合并到主干之前，能够充分的自动化测试，单元测试，只要有一个单元测试未通过，则无法集成到主干。
举例，GitHub中开源的项目，都是由全球开发者一起开发完成的，这些开发人员遍布全球，相互都是通过网络沟通，通过制定规范，每天上百次提交代码，如果没有CI服务器来自动化测试他们几百人提交的代码，做一些基础性的检查，估计做这个工作的人得累吐血了，程序员最不喜欢重复劳动，都有极客精神，有些无法忍受这样的情况，发明了一些CI新的软件解决问题。CI服务器可以很好的帮助把集成代码做统一的单元测试，语法、编程规范检测，程序完整性等等前置条件。
在code review时，代码已经可用，常规性的检测CI已经完成，并且会自动给开发人员反馈CI测试报告。review的人专注在代码实现逻辑检测，是否符合产品功能需求。
通过一个中心源代码仓库，大家共同协作，每次提交之后，自动触发持续集成平台，拉取最新的代码进行测试，让整个平台联动起来，通过每天持续的迭代测试，提高整体的交付产品周期。
好处有三个：
1 | (1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 |
一个完整的持续集成系统必须包括：
- 一个自动构建过程，包括自动编译、分发、部署和测试等。
- 一个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库。
- 一个持续集成服务器。
持续交付
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的预生产环境中更多的测试。如果代码质量管理以及评审通过，具备随时替换线上版本的能力。
持续交付，可以看作是持续集成的下一步，不管你软件怎么更新，必须保证随时可交付能力。
预生产环境，代码通过预生产环境的测试和检验，更加能够保证产品的质量，如果出现问题，更快的反馈问题，可以更容易理解问题出现的位置，并在代码进入生产环境之前将其解决。
持续部署
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
通常需要具备持续部署，出现问题，紧急回滚上一个版本的能力。曾经实现这个目标通常需要使用软连接解决，而现在我们拥有先进的容器技术，可以保障快速版本回滚修复问题。
DevOps
高质量的测试和自动化发布系统（一个高度自动化可持续的流水线式的交付系统）
持续 (Continuous)：不断的获取反馈，响应反馈。
集成 (Integration)：编译、测试、打包；
部署 (Deployment)：应用组件或基本设施的代码或配置变更在产品环境生效称为“部署”；
发布 (Release)：具有业务影响的功能变化对最终用户可见称为“发布”。
交付 (Delivery)：可以理解为Deployment到Release之间的阶段，更多的强调一种能力。开发有能力的持续部署，业务有能力随时发布。
为了高质量的软件交付，组织必须转向自动化流程，手动流程太容易出错，效率低下。对于执行CD和devops的团队来说，自动化变得越来越重要，大家只需要专注在code和review中，其它过程都尽可能的自动化。
代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个release的复杂度和风险越高；代码库存越多，workflow的包袱越重，管理成本越大；
越早通过用户和DevOps建立可持续反馈机制，可以帮助软件产品更好的迭代和修复缺陷，建立完善的反馈机制能够更早的发现问题，让我们更多的时间找到完美的解决问题方案。
参考：