gitlab CI CD基础概念
本文目录
- gitlab CI CD基础概念
- 基础概念
- Pipelines:流水线
- Jobs
- Stage
- .gitlab-ci.yml
- 使用模式1:官网gitlab + 本地gitlab runner
- 使用模式2:docker gitlab + docker gitlab runner
基础概念
开发模式转变:瀑布模型->敏捷开发→DevOps(Development、Operations的组合词,是一组过程、方法与系统的统称)
gitlab官网:https://docs.gitlab.com/ee/ci/
CI(Continuous Integration):持续集成
- 将小的代码块推送到Git仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中
- 将各个开发人员的工作集合到一个代码仓库中,主要目的是尽早发现集成错误
CD(Continuous Delivery):持续交付
- 当每一次更改的代码落库后,不仅会构建和测试,也会进行部署,但是部署需要人工干预,手动的有目的进行部署
CD(Continuous Deployment):持续部署
- 类似于持续交付,但它不是手动部署,而是自动部署,不需要人为干预
官方中文介绍:https://docs.gitlab.cn/ee/ci/introduction/index.html
-
将本地 commits 推送到在 Gitlab 上的远程分支上,就会触发项目的 CI/CD pipelin
-
自动运行(串行或并行)脚本
- 构建和测试应用程序
- 在应用程序中查看修改,检查是否和本地运行一样
-
实施后按预期工作
- 审核并批准代码
- 合并分支,然后 GitLab CI/CD会自动地将更改部署到生产环境中
CI 主要是提交或合并代码的时候触发,负责一些基本规则的检查,如果检查遇到失败,那么回滚或修改代码后再提交或合并,降低代码风险;
CD 主要手动和自动的触发,在CI的基础上,还负责功能检查,如果功能符合验收标准,那么就可以交付或部署。
GitLab 在 DevOps 生命周期的每个阶段提供的功能:
Pipelines:流水线
Jobs
也就是任务,定义了该做什么,比如:编译和测试代码;
Job 是由 Runner 来执行,如果有足够多的并发 Runner,同一个 Stage 的 Job 可以并行执行
Stage
也就是阶段,定义什么时候执行 Jobs,比如:在编译代码的阶段之后进入运行测试的阶段
一般 Pipeline 包含四个 Stage(阶段),按照以下顺序执行:
- 一个 build(构建) 阶段,包含一个 compile 的 job;
- 一个 test(测试)阶段,包含两个 test1 和 test2 的 job;
- 一个 staging(预发) 阶段,包含一个 deploy to stage 的 job;
- 一个 production(生产)阶段,包含一个 deploy-to-prod 的 job。
.gitlab-ci.yml
例子
stages:
- build
- test
build-code-job:
stage: build
script:
- echo "Check the ruby version, then build some Ruby project files:"
- ruby -v
- rake
test-code-job1:
stage: test
script:
- echo "If the files are built successfully, test some files with one command:"
- rake test1
test-code-job2:
stage: test
script:
- echo "If the files are built successfully, test other files with a different command:"
- rake test2
使用模式1:官网gitlab + 本地gitlab runner
直接使用GitLab网站 https://gitlab.com/ 而不在本地部署 GitLab,GitLab 提供一个托管服务,可以免费创建私有或公共代码仓库并使用其 CI/CD 功能。
使用模式2:docker gitlab + docker gitlab runner
本地部署gitlab和gitlab runner,可以完全独立管理,适合公司内部