DevOps

DevOps的实现：基于Docker的开发模式驱动持续集成落地实施

持续集成、持续交付、持续部署

一个产品要经过开发、测试、部署等一系列过程，我们必须有一种可行且稳定的方式实现，使用户使用的产品是没有bug的。

1、持续集成

持续集成的目的有两个：

 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

在持续集成里面我们需要：

1、提交分支代码到版本库
所有后面的步骤都始于本地代码的一次提交（commit）。

2、构建测试环境
所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。

当然，还包括项目的执行环境，比如lamp的搭建。

构建就是要项目能够跑起来。

一篇非常详细的文章，介绍了整个持续集成的流程：基于Docker和Git的持续集成工作流

3、测试

测试的内容有：

单元测试：针对函数或模块的测试
集成测试：针对整体产品的某个功能的测试，又称功能测试
端对端测试：从用户界面直达数据库的全链路测试

我们通过持续集成来保证每个人的代码合并到主干上的时候都是可用的，在这过程中我们会发现大量bug，且必须修复。

2、持续交付

持续交付是持续集成OK之后，到将项目部署到staging环境（预生产环境，是产品在上线之前的预言环境）的过程，

过程包括全面测试和在staging部署，当然，可以根据产品的需要适当增减，但是staging是必须的。

这里的第二测试是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。

注意：
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。

3、持续部署

staging环境下如果OK，那么就可以随时部署到线上了，而部署的方式也有多种。

简单的部署方式：

1、将这个版本staging版本打包`（ tar filename.tar * ）`存档，发到生产服务器。

2、生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。

基于docket的部署方式

基于服务器集群的部署方式

将一个ECS服务器从集群中脱离，将代码部署上去，如果运行OK，再通过到其他ECS上面。

参考：
持续集成是什么？
The Product Managers’ Guide to Continuous Delivery and DevOps