惠州响应式网站哪家好,企业邮箱 网站建设,wordpress 多个站点,html5视频播放器插件CICD是什么?
由于目前公司使用的gitlab#xff0c;大部分项目使用的CICD是gitlab的CICD#xff0c;少部分用的是jenkins#xff0c;使用了gitlab-ci一段时间后感觉还不错#xff0c;因此总结一下
介绍gitlab的CICD之前#xff0c;可以先了解CICD是什么
我们的开发模式…CICD是什么?
由于目前公司使用的gitlab大部分项目使用的CICD是gitlab的CICD少部分用的是jenkins使用了gitlab-ci一段时间后感觉还不错因此总结一下
介绍gitlab的CICD之前可以先了解CICD是什么
我们的开发模式经历了如下的转变瀑布模型-敏捷开发→DevOps(Development、Operations的组合词是一组过程、方法与系统的统称)
后来随着DevOps的兴起出现了持续集成Continuous Integration、持续交付Continuous Delivery 、持续部署Continuous Deployment 的新方法关于持续集成、持续交付、持续部署总结如下
持续集成的重点是将各个开发人员的工作集合到一个代码仓库中。通常每天都要进行几次主要目的是尽早发现集成错误使团队更加紧密结合更好地协作。持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化以便任何时刻能够安全地完成代码发布理想情况下。持续部署是一种更高程度的自动化无论何时对代码进行重大更改都会自动进行构建/部署。
持续集成的好处是什么
持续集成可以使问题尽早暴露从而也降低了解决问题的难度持续集成无法消除bug但却能大大降低修复的难度和时间。
持续交付的好处是什么
持续交付的好处在于快速获取用户反馈适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改那么决定何时上线上线哪部分功能则完全由产品业务团队决定。
虽然持续交付有显著的优点但也有不成立的时候比如对于嵌入式系统的开发往往需要软硬件的配合。
持续部署的好处是什么
持续部署的目标是通过减少批量工作的大小并加快团队工作的节奏帮助开发团队在其开发流程中消除浪费。这使团队能够一直处于一种可持续的平稳流状态 让团队更容易去创新、试验并达到可持续的生产率
市面上的CI有很多如果在github上搜一下ci工具也会搜到很多比如
Travis CICircle CIJenkinsAppVeyorCodeShipDroneSemaphore CIBuildkiteWerckerTeamCity
这里只介绍Gitlab-CI
Gitlab-CI 项目页面 Continuous Integration and Delivery | GitLab 源代码 GitLab.org / GitLab FOSS · GitLab 遵循 MIT 许可协议
GitLab 是 CI/CD 领域的一个新手玩家但它已经在 Forrester Wave 持续集成工具中占据了领先地位。在这样一个竞争对手众多而水平又很高的领域这是一项巨大的成就。是什么让 GitLab CI 如此了不起
它使用 YAML 文件来描述整个管道。它还有一个功能叫 Auto DevOps使比较简单的项目可以自动构建内置了若干测试的管道。使用 Herokuish 构建包来确定语言以及如何构建应用程序。有些语言还可以管理数据库对于构建新的应用程序并在开发过程一开始就将其部署到生产环境中这是一个很重要的功能。提供到 Kubernetes 集群的原生集成并使用多种部署方法的一种如基于百分比的部署和蓝绿部署将应用程序自动部署到 Kubernetes 集群中。
除了 CI 功能之外GitLab 还提供了许多补充功能比如自动把 Prometheus 和你的应用程序一起部署实现运行监控使用 GitLab 问题Issues、史诗Epics和里程碑Milestones进行项目组合和项目管理管道内置了安全检查提供跨多个项目的聚合结果使用 WebIDE 在 GitLab 中编辑代码的能力它甚至可以提供预览或执行管道的一部分以获得更快的反馈。
相关概念
pipeline管道、流水线
一次 Pipeline 其实相当于一次构建任务里面可以包含多个流程Stage比如自动构建、自动进行单元测试、自动进行代码检查等流程 ;任何提交或者 Merge Request 的合并都可以触发 Pipeline ;
Stage构建阶段
Stage表示构建阶段就是上面提到的流程 ;可以在一次 Pipeline中定义多个 Stage;Stage有如下特点 : 所有 stages 会按照顺序运行即当一个 stage 完成后下一个 Stage才会开始只有当所有 Stage 成功完成后该构建任务 Pipeline 才算成功如果任何一个 Stage失败那么后面的 Stage 不会执行该构建任务 (Pipeline) 失败
阶段是对批量的作业的一个逻辑上的划分每个 pipeline都必须包含至少一个 Stage。多个 Stage是按照顺序执行的如果其中任何一个 Stage失败则后续的 Stage不会被执行整个 CI 过程被认为失败。
Jobs任务
job表示构建工作表示某个stage里面执行的工作 ;一个stage里面可以定义多个job ;jobs有如下特点 : 相同 stage 中的jobs 会并行执行相同 stage 中的 jobs 都执行成功时该 stage 才会成功如果任何一个job 失败那么该 stage 失败即该构建任务 (Pipeline) 失败
举一个例子比如下面这个图 这里的四个Statge(阶段): Verify、Build、Dockerpush、Deploy四个这四个阶段组成一条Pipeline
每个阶段都有一个job所以总共四个job也就是unit-test、java-package、docker-push、service-1这四个当然每个stage可以由多个job组成比如下面这个图
Job 的执行过程中往往会产生一些数据默认情况下 GitLab Runner 会保存 Job 生成的这些数据然后在下一个 Job 执行之前甚至不局限于当次 CI/CD将这些数据恢复。这样即便是不同的 Job 运行在不同的 Runner 上它也能看到彼此生成的数据。
.gitlab-ci.yml中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。 关于.gitlab-ci.yml、before_script、after_script是什么先别急在后面有介绍 在了解了 Job 配置的 script、before_script、after_script 和 cache 以后可以将整个 Job 的执行流程用一张图概括 所以了解了Pipeline、Stage、Jobs后还有一个很重要的东西就是Runner
Runner
Runner就像一个个的工人而Gitlab-CI就是这些工人的一个管理中心所有工人都要在Gitlab-CI里面登记注册并且表明自己是为哪个工程服务的。当相应的工程发生变化时Gitlab-CI就会通知相应的工人执行软件集成脚本。如下图所示 gitlab里面的runner叫Gitlab-RunnerGitlab-Runner是配合Gitlab-CI进行使用的。一般地Gitlab里面的每一个工程都会定义一个属于这个工程的软件集成脚本用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时比如有人push了代码GitLab就会将这个变动通知Gitlab-CI。这时Gitlab-CI会找出与这个工程相关联的Runner并通知这些Runner把代码更新到本地并执行预定义好的执行脚本(也就是在Job执行流程那个图中所示的第三步script)所以Gitlab-Runner就是一个用来执行软件集成脚本script的东西。
Runner类型
Gitlab-Runner可以分类两种类型Shared Runner共享型和Specific Runner指定型。
Shared Runner这种Runner工人是所有工程都能够用的。只有系统管理员能够创建Shared Runner。Specific Runner这种Runner工人只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。
关于Gitlab-runner的安装会以单独一个文章进行介绍注册runner会对应一个tag记住这个tag
.gitlab-ci.yml简介
.gitlab-ci.yml 文件被用来管理项目的 runner 任务Gitlab CI通过.gitlab-ci.yml文件管理配置job该文件定义了statge顺序、job应该如何触发和工作、执行什么脚本、如何构建pipeline等流程 该文件存放于仓库的根目录, 默认名为.gitlab-ci.yml 我们先看一个简单的例子.gitlab-ci.yml
## 定义pipeline流程verify-build-dockerpush-deploy
stages:- verify- build- dockerpush- deploy#单元测试
unit-test:stage: verify # 属于哪个流程tags:- test-cicd # 在哪个runner上面执行在注册runner可以自定义script:- echo unit-test # 执行脚本#java编译
java-package:stage: buildtags:- test-cicdscript:- echo build#push镜像
docker-push:stage: dockerpushtags:- test-cicdscript:- echo docker-push#deploy
service-1:stage: deploytags:- test-cicdscript:- echo deploy该配置对应下面的pipelinetest-cicd是一个Specific Runner执行脚本的类型是shell 所以以unit-test这个job为例点击该任务可以进入到log界面查看整个log执行流程 剩下的job的执行日志都大部分如此就不一一列举了
几个重要的关键字解析
关于gitlab-ci.yml里面有很多关键字配置下面我主要列举一些比较常用的关键字
before_script和after_script
随着项目越来越大Job 越来越多Job 中包含的重复逻辑可能会让配置文件臃肿不堪。.gitlab-ci.yml 中提供了 before_script 和 after_script 两个全局配置项。这两个配置项在所有 Job 的 script 执行前和执行后调用。
before_script 和 script 在一个上下文中是串行执行的after_script 是独立执行的。所以根据执行器(在runner注册的时候可以选择执行器docker,shell 等)的不同工作树之外的变化可能不可见例如在before_script中执行软件的安装。
你可以在任务中定义 before_scriptafter_script也可以将其定义为顶级元素定义为顶级元素将为每一个任务都执行相应阶段的脚本或命令。
stages
stages的允许定义多个灵活的场景阶段的pipline。定义的元素的顺序决定了任务执行的顺序。例如
## 定义pipeline流程verify-build-dockerpush-deploy
stages:- verify- build- dockerpush- deploybuild场景的任务将被并行执行。test、deploy 同理build 任务成功后test 执行。test 成功后deploy 执行所有的都成功了提交将会标记为成功任何一步任务失败了提交标记为失败并之后的场景任务都不回执行。
tags
tags可以从允许运行此项目的所有Runners中选择特定的Runners来执行jobs。
在注册Runner的过程中我们可以设置Runner的标签tags可通过tags来指定特殊的Runners来运行jobs
#单元测试
unit-test:stage: verify # 属于哪个流程tags:- test-cicd # 在哪个runner上面执行在注册runner可以自定义script
script是一段由Runner执行的shell脚本可以执行多个例如
job:script: mvn clean test这个参数也可以使用数组包含好几条命令
job:script:- pwd- mvn clean testonly and except
only和except两个参数说明了job什么时候将会被创建:
only定义了job需要执行的所在分支或者标签except定义了job不会执行的所在分支或者标签
以下是这两个参数的几条用法规则
only和except如果都存在在一个job声明中则所需引用将会被only和except所定义的分支过滤.only和except允许使用正则only和except可同时使用。如果only和except在一个job配置中同时存在则以only为准跳过except(从下面示例中得出)。only和except允许使用特殊的关键字branchestags和triggers。only和except允许使用指定仓库地址但不是forks的仓库(查看示例3)。
例子解析
1.job将会只在issue-开头的refs下执行反之则其他所有分支被跳过
job:# use regexponly:- /^issue-.*$/# use special keywordexcept:- branches2.job只会在打了tag的分支或者被api所触发或者每日构建任务上运行
job:# use special keywordsonly:- tags # tag 分支 commit 之后触发- triggers # API 触发- schedules # 每日构建触发3.job将会在父仓库gitlab-org/gitlab-ce的非master分支有提交时运行。
job:only:- branchesgitlab-org/gitlab-ceexcept:- mastergitlab-org/gitlab-cewhen
when可以设置以下值
on_success - 只有前面stages的所有工作成功时才执行。 这是默认值。on_failure - 当前面stages中任意一个jobs失败后执行。always - 无论前面stages中jobs状态如何都执行。manual - 手动执行(GitLab8.10增加)。
stages:
- build
- cleanup_build
- test
- deploy
- cleanupbuild_job:stage: buildscript:- make buildcleanup_build_job:stage: cleanup_buildscript:- cleanup build when failedwhen: on_failuretest_job:stage: testscript:- make testdeploy_job:stage: deployscript:- make deploywhen: manualcleanup_job:stage: cleanupscript:- cleanup after jobswhen: always脚本说明
只有当build_job失败的时候才会执行cleanup_build_job 。不管前一个job执行失败还是成功都会执行cleanup_job 。可以从GitLab界面中手动执行deploy_jobs。
manual
在GitLab的用户界面中显示该作业的“播放”按钮意味着deploy_job仅在单击“播放”按钮时才会触发job。
修改上面那个例子
stages:- verify- build- dockerpush- deploy- cleanupbefore_script:- pwd
after_script:- echo after_script#单元测试
unit-test:stage: verifytags:- test-cicdscript:- echo unit-test#java编译
java-package:stage: buildtags:- test-cicdscript:- echo build#push镜像
docker-push:stage: dockerpushtags:- test-cicdscript:- echo docker-push#deploy
service-1:stage: deploytags:- test-cicdscript:- echo deploywhen: manual # 手动触发job只有点击按钮才会触发cleanup_job:stage: cleanupscript:- echo clean upwhen: always # 前面的job成功与否都会执行该jobpipeline如下: allow_failure
跟when一起控制job执行与否的配置还有一个就是allow_failure
allow_failure可以用于当你想设置一个job失败的之后并不影响后续的CI组件的时候。失败的jobs不会影响到commit状态。
下面的这个例子中java-package和java-package2将会并列进行如果java-package2失败了它也不会影响进行中的下一个stage因为这里有设置了allow_failure: true。
stages:- verify- build- dockerpush- deploy- cleanupbefore_script:- pwd
after_script:- echo after_script#单元测试
unit-test:stage: verifytags:- test-cicdscript:- echo unit-test#java编译
java-package:stage: buildtags:- test-cicdscript:- echo build#java编译
java-package2:stage: buildtags:- test-cicdscript:- execute_script_that_will_fail # 该shell会导致job执行失败allow_failure: true # 不影响后面的任务进行#push镜像
docker-push:stage: dockerpushtags:- test-cicdscript:- echo docker-push#deploy
service-1:stage: deploytags:- test-cicdscript:- echo deploywhen: manualcleanup_job:stage: cleanuptags:- test-cicdscript:- echo clean upwhen: alwaysjava-package2会执行错误 运行的pipeline如下可见java-package2的执行错误 variables
GitLab CI允许你为.gitlab-ci.yml增加变量该变量将会被设置入任务环境。通过两种方式可以引用
美元符大括号引用${}美元符$
示例如下
variables:SOFT_VERSION: 1.0TAG_NAME: xxx
#构建镜像
docker-build:stage: dockerpushtags:- test-cicdscript:- docker build -t $TAG_NAME:${SOFT_VERSION}如果有些值不想在配置文件中显示比如密码什么的可以在代码仓库中setting-CICD-Variables 自定义变量跟在.gitlab-ci.yml配置变量效果是一样的 variables的保留字
gitlab-ci有一些预定义变量这些变量大部分以CI开头
预定义变量
VariableGitLabRunnerDescriptionCIall0.4标识该job是在CI环境中执行CI_COMMIT_REF_NAME9.0all用于构建项目的分支或tag名称CI_COMMIT_REF_SLUG9.0all先将$CI_COMMIT_REF_NAME的值转换成小写最大不能超过63个字节然后把除了0-9和a-z的其他字符转换成-。在URLs和域名名称中使用。CI_COMMIT_SHA9.0allcommit的版本号CI_COMMIT_TAG9.00.5commit的tag名称。只有创建了tags才会出现。CI_DEBUG_TRACE9.01.7debug tracing开启时才生效CI_ENVIRONMENT_NAME8.15alljob的环境名称CI_ENVIRONMENT_SLUG8.15all环境名称的简化版本适用于DNSURLsKubernetes labels等CI_JOB_ID9.0allGItLab CI内部调用job的一个唯一IDCI_JOB_MANUAL8.12all表示job启用的标识CI_JOB_NAME9.00.5.gitlab-ci.yml中定义的job的名称CI_JOB_STAGE9.00.5.gitlab-ci.yml中定义的stage的名称CI_JOB_TOKEN9.01.2用于同GitLab容器仓库验证的tokenCI_REPOSITORY_URL9.0allgit仓库地址用于克隆CI_RUNNER_DESCRIPTION8.100.5GitLab中存储的Runner描述CI_RUNNER_ID8.100.5Runner所使用的唯一IDCI_RUNNER_TAGS8.100.5Runner定义的tagsCI_PIPELINE_ID8.100.5GitLab CI 在内部使用的当前pipeline的唯一IDCI_PIPELINE_TRIGGEREDallall用于指示该job被触发的标识CI_PROJECT_DIRallall仓库克隆的完整地址和job允许的完整地址CI_PROJECT_IDallallGitLab CI在内部使用的当前项目的唯一IDCI_PROJECT_NAME8.100.5当前正在构建的项目名称事实上是项目文件夹名称CI_PROJECT_NAMESPACE8.100.5当前正在构建的项目命名空间用户名或者是组名称CI_PROJECT_PATH8.100.5命名空间加项目名称CI_PROJECT_PATH_SLUG9.3all$CI_PROJECT_PATH小写字母、除了0-9和a-z的其他字母都替换成-。用于地址和域名名称。CI_PROJECT_URL8.100.5项目的访问地址http形式CI_REGISTRY8.100.5如果启用了Container Registry则返回GitLab的Container Registry的地址CI_REGISTRY_IMAGE8.100.5如果为项目启用了Container Registry它将返回与特定项目相关联的注册表的地址CI_REGISTRY_PASSWORD9.0all用于push containers到GitLab的Container Registry的密码CI_REGISTRY_USER9.0all用于push containers到GItLab的Container Registry的用户名CI_SERVERallall标记该job是在CI环境中执行CI_SERVER_NAMEallall用于协调job的CI服务器名称CI_SERVER_REVISIONallall用于调度job的GitLab修订版CI_SERVER_VERSIONallall用于调度job的GItLab版本ARTIFACT_DOWNLOAD_ATTEMPTS8.151.9尝试运行下载artifacts的job的次数GET_SOURCES_ATTEMPTS8.151.9尝试运行获取源的job次数GITLAB_CIallall用于指示该job是在GItLab CI环境中运行GITLAB_USER_ID8.12all开启该job的用户IDGITLAB_USER_EMAIL8.12all开启该job的用户邮箱RESTORE_CACHE_ATTEMPTS8.151.9尝试运行存储缓存的job的次数
更多配置可以参考官方参考文档CI/CD YAML syntax reference | GitLab
