自动化运维持续集成

互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称 CI）。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。讨论关注以下几点：

1. 持续集成概念的理解。
2. 了解持续交付和持续部署。
3. 熟悉持续集成操作流程。

一、概述

当前软件的开发和发布过程中，已经有了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称 CI），为 Devops 平台提供了一个良好的基础。

开发团队 -> 源代码编码（开发语言）-> 代码版本控制（Gitlab） -> Docker 构建（创建镜像）-> 静态代码分析（白盒测试）-> 自动化单元测试 -> 代码覆盖率（覆盖率测试）-> Docker 版本（发布到容器）-> 提供部署到测试环境 -> 自动化功能测试 -> 发布报告 -> 生产部署

二、持续集成

1. CI 过程：代码编写 -> 源代码库（GitHub or gitlab）-> CI 服务器（代码构建、自动化测试、结果反馈【构建结果】）
2. 涉及 CI 工具：Jenkins、Travis CI、TeamCity、Gitlab CI、CircleCI、Codeship 等，相关资料可以查询对应的官网，其中应用广泛的 Jenkins 和 Travis CI，Gitlab CI 是开源的 Rails 项目 GitLab 的一个组成部分，GitLab CI 能与 GitLab 完全集成，可以通过使用 GitLab API 轻松地作为项目的钩子。

持续集成构建目的：

1. 及早发现集成错误，且由于修订的内容较小所以易于追踪，这可以节省专案的时间与成本。
2. 避免发布日期的前一分钟发生混乱，当每个人都会尝试为他们所造成的那一点点不相容的版本做检查。
3. 当单元测试失败或发生错误，若开发人员需要在不除错的情况下还原程式码库到一个没有问题的状态，只需要放弃一小部份的更改（因为集成的次数频繁）。
4. 让“最新”的程式可保持可用的状态供测试、展示或发布用。
5. 频繁的提交程式码会促使开发人员建立模组化，低复杂性的程式码。

持续集成自动化测试目的：

1. 强制执行频繁的自动化测试纪律
2. 当改变对全系统造成影响时立即反馈
3. 自动化测试和持续性集成产生的软件度量（如代码覆盖度量，代码复杂度和功能完整性等）标准将开发人员集中在开发功能性，高品质的程式码上，并帮助开发团队发展。

持续集成存在的问题：

1. 构建一个自动化测试套件需要大量的工作，包括不断努力以覆盖新功能，并依照特定情境进行程式码修改，持续性集成可以在不需要测试套件下执行，但是必须手动和经常地完成，生产产品的品质保证成本将会提高。
2. 构建构建系统需要一些工作，而且可能变得复杂，难以灵活修改。但是，也有一些开放源代码的持续集成的专案软件可以使用。
3. 如果范围很小或包含无法测试的旧版代码，持续性集成不一定有价值。
4. 增加的价值取决于测试的品质以及代码的真实可测性。
5. 较大的团队意味著不断将代码添加到集成队列中，因此追踪交付（同时保持品质）很困难，而排队可能会减慢所有人的进度。
6. 通过一天的多次提交和合并，功能的部分代码可以轻松推送，如此一来集成测试将会失败直到整个功能开发完成。

三、持续交付（Continuous delivery，缩写为 CD）

持续集成 -> 再次测试 -> 结果发布

1. CD 是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建立、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
2. 持续交付与 DevOps 的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps 的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付的过程自动化。另一方面，持续交付是一种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。因此，DevOps 可以是持续交付的一个产物，持续交付直接汇入 DevOps。
3. 持续交付也与持续部署混淆。持续部署意味著所有的变更都会被自动部署到生产环境中。持续交付意味著所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。

四、持续部署（Continuous Deployment）

持续部署则是在持续交付的基础上，把所有的变更自动部署到生产环境中。

1. 通过以上步骤后，形成一个最终可以部署的版本（artifact），并将相关的版本打包成便于部署的文件包，如：tar.gz、jar 包、war 包等，发布到生产环境。
2. 架设 nexus 私服从内网获取下载依赖库，使用 nexus 私服仅在依赖库第一次获取时需要从中央仓库或其他 maven 仓库中获取，之后便可从内网获取。生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有 Ansible、Chef、Puppet 等。
3. 通过配置管理工具将相应的程序包和配置文件及相关命令或脚本发布到生产服务器，并根据相关的操作来完成这一部署过程。整个部署过程按照（如：ansible-playbook 执行 playbook.yml 来完成）

五、持续集成操作流程

编码 -> 构建 -> 整合 -> 测试 -> 交付 -> 部署 -> 回滚

1. 代码编写，完成代码功能模块。
2. 构建，实现功能模块构建测试，保证该模块当前的可用状态。
3. 测试，单元测试和集成测试，保证各个功能模块的完整性和稳定性。
4. 交付，建立在CI基础上，让软件的构建、测试与最终版本变得更快以及更频繁。
5. 部署，是在持续交付的基础上，把部署到生产环境的过程自动化。
6. 回滚，一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。

Docker + Jenkins + Git 发布 Java 项目持续构建案例

Java 项目开发 -> 提交项目代码 Git 容器 -> Jenkins 容器拉取项目代码 -> Maven 编译构建项目 -> Jenkins 发布项目到 Tomcat 容器 -> 测试

---

本文首发于GitChat，未经授权不得转载，转载需与GitChat联系。

阅读全文: http://gitbook.cn/gitchat/activity/5b0e3ca06d42850a8da37962

您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。