最近做了一些持续集成相关的东西
定义
- 持续集成（continuous integration，缩写：CI），维基百科上面的解释是：is the practice of merging all developer working copies to a shared mainline several times a day。意译为：在团队协作中，一天里多次将所有开发人员的代码merge到同一条主干上。
- 大公司的持续集成可以复杂到非常复杂(就是复杂到不可描述了，比如阿里云的专有云)，小公司的持续集成也可能简单到只是一个系统部署过程。
- 瀑布模型中，软件的开发过程大概可以分成这几部：需求分析 -> 系统设计 -> 编码实现 -> 测试 -> 集成 -> 部署 -> 维护。这里面所谓的【集成】就是在存在多个系统协作的情况下，将子系统集成为一个大系统的过程。而我理解的敏捷开发，实际上就是在瀑布模型的基础上，加入持续迭代，既：需求不是一次全部确定清楚，每次可能只确定了一个部分，这部分开发、测试、集成、部署以后，进入下一个需求的开发，重复上述过程。
而持续集成可以说是敏捷开发的最佳实践。 -
持续集成的关键不是集成，而是持续。所谓持续，就需要自动化。代码的每次合并都会触发持续集成服务器进行自动构建，这个过程包括了编译、单元测试、集成、集成测试、质量分析、性能测试等步骤，每一步的结果只有两个：成功或者失败。这一步成功以后，才能进入到下一步，这一步失败，就说明有人提交的代码有问题。 -
每个团队的持续集成应该根据自己产品的实际需求来确定集成步骤，关键在于持续，而不是步骤。不考虑实际业务需求的设计，都是耍流氓，我们应该秉承的是：在现阶段，以最好的方式，完成所需的功能，而不是一味的追求扩展性，也不是一味的追求技术深度，更不是随便一种的简单实现。
持续交付和持续部署
- 持续交付的目标是让软件在短周期内产出，确保软件随时可以被可靠地发布，目标是持续产出可以可靠发布的软件。我理解持续交付需要依赖于持续集成，在持续集成的过程中，通过了所有测试case并且可以正确发布的集成系统，就可以作为持续交付的结果。持续交付与DevOps的含义很相似。
- 持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
我做了什么
- 啰嗦了这么多，其实我做的算是持续部署，就是用Jenkins给我们后台系统，做了一个持续部署。🤣
- 使用到的主要是Jenkins pipeline。首先在centos 7.1系统上直接运行了jenkens blueocean的docker版本(有做volume的映射，可以保存docker运行时数据)
- 然后在Jenkins里面定义了一个pipeline的job，pipeline里面定义了这么几个部分：拉取代码->编译->测试case->代码打tag->二进制文件上传到某个仓库->脚本化部署到各个机器。
- 每次有代码merge到master分支，都会以hook的方式触发Jenkins job，执行持续集成，所有步骤通过以后，线上就会完成自动化部署。
- 有一点儿需要注意的是，jenkins可以创建多个job，而每个job可能会同时运行，而同一个job也可能同时被多次执行。为了解决冲突问题，所有的jenkins job都在docker中运行。这里的docker是我自己构建的，为了满足我们自己的脚本化需求，和部署需求，有一些依赖需要添加。
- 我理解这个过程中比较重要的是：
1) 持续，每次有代码merge到master，都会触发持续部署。2) 测试，测试在持续集成、持续交付和持续部署中有着至关重要的作用，没有完备的测试case，就无法保证部署上去的系统是可用系统。
