GitLab与Jenkin 结合构建持续集成环境

蟹黄堡！

已于 2022-06-28 16:28:41 修改

阅读量945

点赞数 1

分类专栏： GitLab 与 Jenkins 结合构建持续集成环境文章标签： git 运维自动化 jenkins

于 2022-06-28 16:27:38 首次发布

本文链接：https://blog.csdn.net/JinLu_/article/details/125502260

版权

GitLab 与 Jenkins 结合构建持续集成环境专栏收录该内容

2 篇文章 1 订阅

订阅专栏

1.持续集成概述运行及流程

1.1 CI/CD 介绍

把开发工作流程分为以下几个阶段：

编码 → 构建 → 集成 → 测试 → 交付 → 部署

持续集成（Continuous Integration)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)有着不同的软件自动化交付周期。

概念:

持续集成（CI）：

持续集成（Continuous integation）可以频繁的（一天多次）将代码合并到主干源码仓库，并立刻进行构建、（单元）测试，根据测试结果可以确定新代码和原代码能否确定的集成在一起

好处有两个：

1.快速发现错误，每完成一点开发，集成到主干，可快速发现错误，定位错误

2.防止分支发幅偏离主干，主干又在不断更新，如不是经常集成会导致以后集成的难度变大

集成的目的：就是让产品可以快速迭代，同时还能保存高质量。核心措施是，代码集成到主干之前，必须通过自动化测试，只要又一个测试失败，就不能集成。

持续交付：

持续交付（Continuous delivery）指的是在持续集成的基础上，将集成后的带代码部署到贴近真实生产环境的（类生产环境）中。

持续交付可以看作持续集成的下一步，强调的是，不管怎么更新，软件是随时随地可以交付的。

持续部署：

持续部署（continuous deployment）是持续交付的下一步，指带代码通过评审以后。部署到生产环境。

持续部署的前提是能自动化完成测试、构建、部署等步骤，一般持续部署建立手动部署

总的来说，CI/CD 提供了一个优秀的 DevOps 环境，很大的提高了开发运维的效率

1.2流程

1）提交：

开发者向代码库提交代码

2）测试：

代码仓库对 commit 操作配置了钩子（hook），只要提交代码或合并进主干，就会通知jenkins 实现自动化测试

测试的几种方式：

单元测试：针对函数或模块的测试

集成测试：针对整体产品某个功能的测试又称功能测试

端对端测试：从用户界面直达数据库的全链路测试

3）构建：

通过第一轮测试，代码就可以合并进主干，就算可以交付了。

交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等

4）测试（第二轮）

将 CI 测试后的代码程序交付给测试人员进行全面测试（类生产环境中测试）

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

5）部署

测试成功，当前代码就是一个可以直接部署的版本了。将这个版本的所有文件打包（ tar filename.tar * ）存档，部署生产服务器。

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

6）回滚

如当版本出现问题，回滚到上一个版本的构建，最简单的方法就是修改一下符号链接，指向上一个版本的目录。

1.3 Jenkins 概述

Jenkins 概述：是一个开源软件项目，是基于Java开发的一种持续集成、交付、部署的基于web界面的平台，用于自动化各种任务，包括构建、测试和部署软件。

Jenkins其实很早之前就有了，最近火起来的原因是，大家都在关注devops，关注如何来做CI/CD。Jenkins作为持续集成的工具，他其实只是一个平台或者是一个大的框架，它的工作完全就是依靠插件，也就是说你想使用什么功能，你就找到什么样的插件。
官方网址：Jenkins

1.4 GitLab 概述

gitlab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web界面进行访问公开的或者私人项目。Ruby on Rails 是一个可以使你开发、部署、维护 web 应用程序变得简单的框架。

GitLab 拥有与Github 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

注：gitlab-ce 社区版，gitlab-ee 企业版（收费）

官网： The One DevOps Platform | GitLab

1.5 项目部署方式

项目部署方式分为 2 种：手动、自动部署。

手动部署：

自动化部署：

“自动化”的具体体现：向版本库提交新的代码后，应用服务器上自动部署，用户或测试人员使用的马上就是最新的应用程序

构建上述集成环境可以把整个构建、部署过程自动化，很大程度上减轻工作量。对于程序员的日常开发来说不会造成任何额外负担，自己把代码提交上去之后，服务器上运行的马上就是最新版本。

1.6集群和分布式

通过此图可以形象的解释集群和分布式的含义：

单机结构中的全栈意思是：即做前端的 js、css、html等，又做后端的java 等

集群结构中的全栈意思是：同时又两个或多个更多的人即做前端，又做后端

分布式的意思就是此图所表示的：将后端和前端分开，各做各的。

1.7持续集成系统的工作流程

这里是选择 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在一次集成中需要执行的任务