基础概念：
1、什么是持续集成？
持续集成（Continuous Integration）指的是，频繁地将代码集成到主干，以便快速发现错误、防止分支大幅度偏离主干。
持续集成的目的，就是在产品快速迭代的同时保持代码质量，它的核心措施主要有两点：
1）代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。
2）通过Code Review、代码质量分析工具对代码质量进行把关，以便确定是否能够集成。
Martin Flower说过， “持续集成并不能消除Bug，而是让他们非常容易发现和改正。”
从图例上来看持续集成的流程就十分清晰了：
- 开发人员提交代码到 Source Repository （源代码仓库），并通过 git hook 等
- 触发 CI Server（持续集成服务器）的相关功能。执行 编译 -> 测试 -> 输出结果 的流程，
- 向开发人员反馈结果的 report
可以看出，持续集成的 核心 在于 确保新增的代码能够与原先代码正确的集成。与后续要介绍的持续交付以及持续部署，其最主要的差别也就在于其目标不同。
不过持续集成的流程还存在一定的异议：上图所示的流程为 Build -> Test，在阮老师的教程里头是 Test -> Build。不过，持续集成本身只不过是一种软件工程的方法或者策略，其并不规定具体的实现。在实际的应用中，还是需要结合具体的开发语言或者工具来定。
持续集成的优势
和我们一直在使用的 阶段集成（完成一个阶段的开发后执行代码的集成） 相比， 持续集成 的策略能够为我们带来哪些好处呢？
- 易于定位错误：每一次的代码集成都需要执行相关的测试工作，持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块，也就使得每一次测试中遇到的错误能够更加容易的被定位；
- 易于控制开发流程：更为细致的工作提交也就意味着更容易判断当前的工作进度，这对于管理者规划开发流程而言提供了一个有效的参考，同时也为开发人员省下了汇报工作的时间；
- 易于CodeReview：对于大块工作的切分自然也有助于做 CodeReview；
- 易于减少不必要的工作：build 以及 test 过程的自动化可以为你节约一大票的时间，从而投入到有价值的工作中去。
2、什么是持续交付？
持续交付（Continuous Delivery）指的是，新版本为了能够快速安全的交付到生产环境中，需要将新版本先交付到类生产（Production-like）环境中（如UAT／Staging／Lab环境），以便进行相应的业务验证、安全验证、性能验证等过程。
一旦类生产环境验证通过，新版本就进入到生产阶段。
持续交付可以看作是持续集成的进一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
可以看到，与 持续集成 相比较，持续交付 添加了 Test -> Staging -> Production 的流程，也就是为新增的代码添加了一个保证： 确保新增的代码在生产环境中是可用的 。
在这一增加的流程中，Test 环节不仅仅包含基本的单元测试，还需要延伸到更为复杂的功能测试以及集成测试等。在这里，Staging 指的是 类生产环境 ，其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟，从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈，每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后，将由相关人员对其进行 手动部署到生产环境。
3、什么是持续部署？
持续部署（Continuous Deployment）指的是，新版本通过类生产环境的验证后，自动部署到生产环境中。
持续部署可以看成持续交付的进一步。持续部署的前提是自动化完成测试、构建、验证等步骤。
持续部署的目标是，代码在任何时刻都可以进入自动地进入生产阶段，为最终用户提供服务。
可以看到，同 持续交付 相比 持续集成 的区别体现在对 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。
总结
我对于 持续集成、 持续交付 和 持续部署 三者的理解是：
- 持续集成 是三者中最简单的，同时也是开销最低的。由于不需要类生产环境的配合，测试环境也可以仅支持单元测试的执行，使得持续集成的实现是最为便宜的。考虑到现实开发过程的种种限制，向资源与成本做妥协，舍弃持续交付或者持续部署这样看起来很美的方法，退而转向持续集成也是很合理的选择；
- 持续交付 面向开发初期或者软件稳定性或者安全性要求较高的领域，新增代码提交、编译、测试等一系列环节均可以通过自动化工具完成，很好的节约了人力资源的同时，还对新增代码的功能进行了有效的保障。在手动执行的部署环节，还可以添加在执行完毕标准测试之外的可能需求，以保证发布功能的可靠；
- 持续部署 面向稳定的发布上线后的功能更新。自动的，无需人工干预的部署可以保证新增功能第一时间被发布到生产环境中，确保其尽快的被用户所使用。其与持续交付相比，就在于其功能可靠性与功能及时性的侧重不同。
那么，在哪里能买得到呢？ 该怎么对这些方法进行使用呢？
这就需要相关工具的配合协作了，以前端开发为例：
- 持续集成的工具有：Travis CI、Circle CI、jenkins 等
- 测试框架有：jasmine、mocha 等
- 测试运行器有：karma 等
- 构建工具有：grunt、gulp 等
- balabala…
DevOps 的技术栈与工具链
Everything is Code，DevOps 也同样要通过技术工具链完成持续集成、持续交付、用户反馈和系统优化的整合。Elasticbox 整理了 60+ 开源工具与分类，其中包括版本控制&协作开发工具、自动化构建和测试工具、持续集成&交付工具、部署工具、维护工具、监控，警告&分析工具等等，
补充了一些国内的服务，可以让你更好的执行实施 DevOps 工作流。
- 版本控制&协作开发：GitHub、GitLab、BitBucket、SubVersion、Coding、Bazaar
- 自动化构建和测试:Apache Ant、Maven 、Selenium、PyUnit、QUnit、JMeter、Gradle、PHPUnit
- 持续集成&交付:Jenkins、Capistrano、BuildBot、Fabric、Tinderbox、Travis CI、flow.ci Continuum、LuntBuild、CruiseControl、Integrity、Gump、Go
- 容器平台: Docker、Rocket、Ubuntu（LXC）、第三方厂商如（AWS/阿里云）
- 配置管理：Chef、Puppet、CFengine、Bash、Rudder、Powershell、RunDeck、Saltstack、Ansible
- 微服务平台：OpenShift、Cloud Foundry、Kubernetes、Mesosphere
- 服务开通：Puppet、docker Swarm、Vagrant、Powershell、OpenStack Heat
- 日志管理：Logstash、CollectD、StatsD
- 监控，警告&分析：Nagios、Ganglia、Sensu、zabbix、ICINGA、Graphite、Kibana
