使用持续集成应该是一个软件开发工程师的自觉。 ——沃兹基.索德

前言

在实际工作中，为了防止当前分支大幅度偏离主干，开发人员每天都会频繁地将代码集成到主干。如果不使用持续集成，人工重复进行编译部署等工作，无疑是低效且易出错的。所以持续集成的优点显而易见：
1. 减少人工编译部署过程中的低级错误
2. 缩短开发周期，快速进行版本迭代
3. 随时可部署
4. 让开发人员专心coding（高效）

作者之前也尝试了Jenkins。Jenkins作为老牌的持续集成框架，在这么多年的发展中，积累很多优秀的插件工具，不可否认它具有很多GitLab CI不具备的功能，但是Jenkins的使用复杂度跟GitLab CI 相比还是高了不止一点（不信往下看）。而且我觉得Jenkins的页面设计太out。如果你跟我一样是个初学者，还是建议你从GitLab CI开始尝试。

一点理论

在实践之前我们先介绍一些GitLab CI的相关概念。

pipeline

每次代码提交就会触发一次pipeline。一次pipeline可以看成一次构建任务。构建任务一般会包含：安装依赖，测试，编译，部署服务等多个阶段。

stage

stage就是上述构建任务中的各个构建阶段。一个pipeline可以定义多个stage。stage有以下特点：

1.所有的stage按顺序运行，前一个stage完成后，下一个stage才会开始执行。

2.只有当所有的stage都完成后，该构建任务(pipeline)才会成功。

3.如果一个stage失败，那么下一个stage不会执行，该构建任务(pipeline)失败。

job

job表示构建工作，是每个stage构建阶段里具体执行的工作。跟pipeline与stage的关系类似，stage与job也是一对多的关系，即一个stage里可以定义多个job，而job具有以下特点：

1.同一个 stage 中的 jobs 会并行执行

2.同一个 stage 中的 jobs 都执行成功时，该 stage 才会成功

3.如果任何一个 job 失败，那么该 stage 失败，即该构建任务 (pipeline) 失败

GitLab runner

在了解了上面几个主要概念之后，我们对GitLab CI的工作流程应该大致已经清晰了，即下图：

但是还有一个疑问就是：谁去统筹做上面一系列的事情呢？就是GitLab runner。

工作流程

综合上述理论，要使用GitLab CI，我们首先要在项目的根目录下添加一个 .gitlab-ci.yml 文件，用来定义我们的stages，jobs等一系列具体内容，好让GitLab runner据此来完成它的工作。然后需要在服务器（开发或生产环境）上，配置一个GitLab runner，好让GitLab runner去统筹持续集中过程中的所有事。

一点实践

作者在自己的GitLab上初始化了一个express项目作为例子，带大家来实践一下。

配置 .gitlab-ci.yml 文件

Configuration of your jobs with .gitlab-ci.yml 这是官方文档。

我简单配置下demo项目的.gitlab-ci.yml文件：

作如下解释：
GitLab runner 会根据这个文件内容进行构建，不难看出整个构建工作分为两个stage（阶段），第一阶段install_deps：安装依赖包，而具体的job内容就是执行:npm install。第二阶段：启动程序。每次代码提交，都会触发这两个构建工作。添加缓存cache是因为每个job执行成功后，runner都会去删除.gitignore中的文件。

安装GitLab runner

GitLab runner的安装很简单。installing-the-runner 官方文档

作者以Ubuntu为例:

1、添加GItLa官方库

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

2、安装runner

sudo apt-get install gitlab-runner

配置GitLab runner

这里我们配置一个specific runner。至于shared runner 和 specific runner的区别，大家可以通过官方文档的介绍，自己去选择，这里不赘述了。Shared vs specific Runners

1、拿到token

在你的项目setting->CI/CD->Runners settings下面找到url和token。

2、进行配置

在服务器上输入以下命令来配置一个runner：

sudo gitlab-runner register

然后根据提示把信息填完。（作者为了简单方便演示。Please enter the executor ：选择的shell。）

查看效果

更改代码并提交，然后在项目的CI/CD–>pipelines选项里直接可以看到构建状态：如图

一点问题

在上面的实践中我遇到的一些坑：
1、npm命令找不到：
因为gitLab runner构建的时候是以runner身份操作服务器的，解决方法是：通过link命令把npm链接到 /usr/local/bin/npm。

总结

如果你的代码仓库使用的是GitLab，那么你好像没有什么理由不使用GitLab CI。

使用GitLabCI持续集成相关推荐

iis cgi 无法使用_ASP.NET Core前后端分离项目使用gitlabci持续集成到IIS
(给DotNet加星标,提升.Net技能) 转自:饭勺oOcnblogs.com/fanshaoO/p/12054985.html 现在好多使用gitlab-ci的持续集成的教程,大部分都是发布到li ...
gitlab 目录tag_【环境搭建】gitlab-ci(持续集成）
背景服务和服务器开始多起来了,一个个搞效率太低,所以准备用持续集成来提高效率原理 gitlab-ci与ci-runner的关系 push到gitlab之后,触发GitLab-CI,GitLab-C ...
GitLab-CI持续集成（CI）的介绍与运行机制
GitLab持续集成(CI)的介绍与运行机制 GitLab-CI GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jen ...
Android 持续集成实践（三）——编写 .gitlab-ci.yml 实现自动化
文章目录前言系列文章 Android 持续集成实践(三)--编写 .gitlab-ci.yml 实现自动化要实现的效果定义 gitlab-ci 工作场景阶段定义 build 任务定义 re ...
Blueprint+Dredd+Gitlab-CI 实现持续集成
0 前言 Blueprint+Dredd+Gitlab-CI这一套工具链用于完成Web API的编写.上传.测试.集成.Blueprint的概念和语法另一篇博客已经有说明了,Dredd的使用我也写了一 ...
『中级篇』docker之CI/CD持续集成-项目生成镜像（76）
原创文章,欢迎转载.转载请注明:转载自IT人故事会,谢谢! 原文链接地址:『中级篇』docker之CI/CD持续集成-项目生成镜像(76) 开始想用docker registry做私有镜像库,后来放弃 ...
Gitlab CI 持续集成的完整实践
来源:https://dwz.cn/mWyVHoSm 借着公司代码库迁移到私有Gitlab的契机,我接下持续集成的工作,实现了对Python服务端代码的单元测试.静态代码分析和接口测试的持续集成.总体 ...
从零入门 Serverless | 教你 7 步快速构建 GitLab 持续集成环境
作者 | 存诚阿里云弹性计算团队本文整理自<Serverless 技术公开课>,"Serverless"公众号后台回复"入门",即可获取系列文章 ...
GitLab CI持续集成配置方案
持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地 ...

使用GitLabCI持续集成

前言

目录

为什么要用GitLab CI/CD