GitLab CI 是开源的持续集成服务, GitLab Runner 是一个开源项目, 用于运作任务, 并把结果发送回 GitLab, 它与 GitLab CI 一起使用.
持续集成
持续 (Continuous integration , 缩写 CI) 是一种软件工程流程, 是将所有软件工程师对于软件的工作副本持续集成到共享主线 (mainline) 的一种举措. 该名称最早由 Grady Booch 在他的布区方法中提出, 不过他并不支持在一天中进行数次集成. 之后举措成为极限编程驱动开发 (TDD) 的作法中, 通常还会搭配自动单元测试. 持续集成的提出主要是为解决软件进行系统集成时面临的各项问题.- 维基百科
持续集成一般包括一些流程:
合并代码 安装依赖 编译 测试 发布
持续集成必须依靠以下原则:
维护一个代码知识库
自动构建, 通过一个单一指令来达成系统建构
一旦代码更改好, 下一个阶段应该要进行所有的测试, 以确保软件开发的成果匹配预期
减少冲突, 一天至少提交一次
每次变更必须要快速完成, 如此一来便可以避免集成问题
尽可能的缩小测试环境和正式环境的差距, 服务虚拟化通常更容易实现这个目标
尽早集成
任何人都可以查看最后的建构的结果
自动部署
持续集成可以快速发现错误, 定位错误也比较容易, 它的目的就是让产品可以快速迭代, 同时还能保证高质量. 核心措施代码集成到主干前, 必须通过自动化测试.
GitLab CI
GitLab CI 是为 GitLab 提供持续集成服务的一整套系统. 在 GitLab8.0 以后的版本是默认集成了 GitLab-CI 并且默认启用的. 使用 GitLab CI 需要在仓库跟目录创建一个 GitLab-ci.YAML 的文件, 它用来指定持续集成需要运行的环境, 以及要执行的脚本. 还需要设置一个 GitLab-runner, 当有代码 push 变更的时候, GitLab-runner 会自动开始 pipeline, 并在 GitLab 上显示持续集成的结果.
GitLab Runner
GitLab Runner 是使用 Go 语言编写的, 可以做为一个二进制文件运行, 不需要特定的语言要求, 他创建了一个持续集成的的环境, 所需要的程序使用 Docker 来安装, 配置好 GitLab Runner 运行的环境. GitLab Runner 实际上都是 docker container, 由 GitLab Runner 来自动创建, 运行的环境由 GitLab Runner 程序控制, 使用 docker 来建立 runner, 使得每一个虚拟环境都干净, 轻量, 相互隔离, 互不影响. GitLab-Runner 一般都是配合 GitLab-CI 使用的, 在 GitLab 里面定义一个属于这个工程的软件集成脚本, 用来自动化地完成一些软件集成工作. GitLab-Runner 执行情况如下:
本地代码改动
变动代码推送到 GitLab 上
GitLab 将这个变动通知 GitLab-CI
GitLab-CI 找出这个工程相关联的 GitLab-runner
GitLab-runner 把代码更新到本地
根据预设置的条件配置好环境
根据预定义的脚本 (一般是. GitLab-ci.YAML) 执行
把执行结果通知给 GitLab
GitLab 显示最终执行的结果
GitLab-runner 可以在不同的主机上部署, 也可以在同一个主机上设置多个 GitLab-runner , 还可以根据不同的环境设置不同的环境, 比如我们需要区分研发环境, 测试环境以及正式环境等.
来源: https://juejin.im/post/5c8e4739e51d45105e163069