持续集成概述及运行流程
目录
1、持续集成概述及运行流程
1.1、CI/CD介绍
1.1.1、概念
1.1.2、流程
1.2、jenkins概述
1.3、GitLab概述：
1.4、项目部署方式
1.5、集群和分布式
1.6、持续集成系统的工作流程
总结：
1、持续集成概述及运行流程
1.1、CI/CD介绍
把开发工作流程分为以下几个阶段：
编码 → 构建 → 集成 → 测试 → 交付 → 部署
正如你在上图中看到，持续集成(Continuous Integration)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)有着不同的软件自动化交付周期。
1.1.1、概念
本文简要介绍持续集成的概念。
- 持续集成
持续集成（Continuous integration）是指开发者在代码的开发过程中，可以频繁的（一天多次）将代码合并到主干源码仓库，并立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
它的好处主要有两个：
- 快速发现错误。每完成一点开发，就集成到主干，可以快速发现错误，定位错误也比较容易；
- 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。持续集成并不能消除Bug，而是让它们非常容易发现和改正。
- 持续交付：
持续交付（Continuous delivery）指的是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中，做更多的测试。如果代码没有问题，就可以手动部署到生产环境。 Staging [ˈsteɪdʒɪŋ] 临时工作台
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
- 持续部署：
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，部署到生产环境。
持续部署的目标是，代码在任何时候都是可部署的，可以进入生产环境。
持续部署的前提是能自动化完成测试、构建、部署等步骤。它于持续交付的区别，可以参考下图：
总的来说，CI/CD提供了一个优秀的DevOPs环境。对于整个开发团队来说，能很大的提升开发效率，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。
1.1.2、流程
根据持续集成的设计，代码从提交到生产，整个过程有以下几步。
- 提交
流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。
- 测试（第一轮）
代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
测试有好几种：
单元测试：针对函数或模块的测试
集成测试：针对整体产品的某个功能的测试，又称功能测试
端对端测试：从用户界面直达数据库的全链路测试
第一轮至少要跑单元测试。
- 构建
通过第一轮测试，代码就可以合并进主干，就算可以交付了。
交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。
常用的构建工具如Jenkins、Travis、Codeship、Strider。Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。
- 测试（第二轮）
构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。
第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。
需要强调的是，新版本的每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署阶段后，很可能会出现严重的问题。
- 部署
通过了第二轮测试，当前代码就是一个可以直接部署的版本了。将这个版本的所有文件打包（ tar filename.tar * ）存档，发到生产服务器。
生产服务器将打包文件，解包成本地的一个目录，再将运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。这方面的部署工具有Ansible，Chef，Puppet等。
- 回滚
一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。
1.2、jenkins概述
Jenkins 概述：是一个开源软件项目，是基于Java开发的一种持续集成、交付、部署的基于web界面的平台，用于自动化各种任务，包括构建、测试和部署软件。
Jenkins其实很早之前就有了，最近火起来的原因是，大家都在关注devops，关注如何来做CI/CD。Jenkins作为持续集成的工具，他其实只是一个平台或者是一个大的框架，它的工作完全就是依靠插件，也就是说你想使用什么功能，你就找到什么样的插件。
jenkins官网：https://jenkins.io/zh/
1.3、GitLab概述：
gitlab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web界面进行访问公开的或者私人项目。Ruby on Rails 是一个可以使你开发、部署、维护 web 应用程序变得简单的框架。
GitLab 拥有与Github 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
注： gitlab-ce 社区版，gitlab-ee 是企业版（收费）
官网：https://about.gitlab.com
1.4、项目部署方式
项目部署方式分2种方式：手动部署、自动化部署。
手动部署：
自动部署：
“自动化”的具体体现：向版本库提交新的代码后，应用服务器上自动部署，用户或测试人员使用的马上就是最新的应用程序。
构建上述集成环境可以把整个构建、部署过程自动化，很大程度上减轻工作量。对于程序员的日常开发来说不会造成任何额外负担，自己把代码提交上去之后，服务器上运行的马上就是最新版本。
1.5、集群和分布式
通过此图可以形象的解释集群和分布式的含义：
单机结构中的全栈意思是：即做前端的js、css、html等，又做后端的java等
集群结构中的全栈意思是：同时有两个或者更多的人即做前端，又做后端
分布式的意思就是此图所表示的：将后端和前端分开，各做各的。
1.6、持续集成系统的工作流程
这里是选择Gitlab作为git server。Gitlab的功能和Github差不多，但是是开源的，可以用来搭建私有git server，也提供非常强大的web GUI，比如开发者互相review源代码的时候就会很方便。
系统的工作流程大概分为以下几步:
1> 开发者将新版本push到git server (Gitlab)。
2> Gitlab随后触发jenkins master结点进行一次build。(通过web hook或者定时检测)
3> jenkins master结点将这个build任务分配给若干个注册的slave结点中的一个，这个slave结点根据一个事先设置好的脚本进行build。这个脚本可以做的事情很多，比如编译，测试，生成测试报告等等。这些原本需要手动完成的任务都可以交给jenkins来做。
4> 我们在build中要进行编译，这里使用了分布式编译器distcc来加快编译速度。
注：
jenkins的工作原理是先将源代码从gitlab中拷贝一份到本地，然后根据设置的脚本进行build。我们可以看出，整个系统的关键就是那个build脚本，用来告诉jenkins在一次集成中需要执行的任务。
总结：
- 开发者向代码仓库提交代码
- 在gitlab仓库设置webhook（钩子），通知jenkins实现CI的自动化测试
- 将CI测试后的代码程序交付给测试人员进行全面测试（类生产环境中测试）
- 将测试后没问的项目部署到生成环境，如果有问题，就回滚到上一个稳定版本