使用Gitlab作为工作仓库进行代码发布及版本控制Gitlab内置了CI/CD的工具这些工具可以用于代码提交的同时完成镜像构建、自动化测试、自动化部署等连续的工作CI: Continuous Integration持续集成CD: Continuous Delivery连续交付CD: Continuous Deployment持续部署这里暂时只讨论CI持续集成部分的工作我们常用CI来做一些自动化工作这种自动化工作会运行在一台集中的机器上比如程序镜像的打包单元测试部署等它可以节省项目开发迭代过程中维护正确的代码所耗费的时间。例比如CI中自动测试在多人协同开发的过程中可能会有频繁的不同分支的代码推送更新使用CI管道可在代码发布的同时触发CI中定义的单元测试操作以便于在开发早期发现错误从而确保所有新代码的提交都不影响项目功能。依赖服务gitlabhttps://www.zongscan.com/demo333/95354.htmlgitlab-runnerhttps://www.zongscan.com/demo333/95355.html后面有时间我也会把我自己的beego项目迁移进docker swarm集群里面来整成自动化持续集成部署方式。1. Gitlab-CI/CD工作流参考下图先了解CI/CD的具体工作流和概念黄色部分为主要涉及的概念将在后文重点说明你当前的代码库托管在Gitlab上且已经为代码仓库配置了gitlab-runner服务它是用来实际执行CI任务的服务器提交代码且根目录中包含一个名为.gitlab-ci.yml文件该文件是用来指定构建、测试和部署流程、以及CI触发条件的脚本其概念类似于docker-compose.yml文件Gitlab检测到.gitlab-ci.yml文件若当前提交符合文件中指定的触发条件则会使用配置的gitlab-runner服务运行该脚本进行测试等工作若.gitlab-ci.yml中定义的某个自动化脚本运行失败将判定为此次CI不通过则需要提交者修复问题代码后重复提交直至自动化CI通过。没有问题的提交才能被项目负责人merge到主分支进行后续的部署工作此文暂不涉及CD自动化部署2. 配置文件介绍.gitlab-ci.yml文件主要的作用是用来指定构建、测试和部署流程、以及CI触发条件的脚本在文件中的定义要运行的脚本要包含的其他配置文件和模板依赖项和缓存要按顺序运行的命令和要并行运行的命令将应用程序部署到的位置。无论您是想自动运行脚本还是手动触发其中的任何一个。脚本被分组到作业中作业作为更大管道的一部分运行。您可以将多个独立作业分组到按定义顺序运行的阶段。CI/CD 配置至少需要一项未隐藏的作业。您应该按照适合您的应用程序并符合您希望执行的测试的顺序组织您的工作。为了可视化该过程假设您添加到作业的脚本与您在计算机上运行的 CLI 命令相同。当您将 .gitlab-ci.yml 文件添加到存储库时GitLab 会检测到它并且名为 GitLab Runner 的应用程序会运行作业中定义的脚本。3. 参数列表值是否必须描述script必须定义由Runner执行的shell脚本或命令extends非必须定义此作业将继承的配置条目image非必须需要使用的docker镜像请查阅该文档services非必须定义所需的docker服务请查阅该文档stage非必须定义一个工作场景阶段默认是testtype非必须stage的别名不赞成使用variables非必须在job级别上定义的变量only非必须定义job所引用的git分支except非必须定义job所不适用的git分支tags非必须定义job所适用的runnertags为runner标签allow_failure非必须when 用于实现在发生故障或发生故障时运行的作业。when 可以设置为以下值之一on_success-仅当先前阶段中的所有作业都成功或因为已标记被视为成功allow_failure时才执行作业。这是默认值。on_failure -仅在前一阶段中的至少一项作业失败时才执行作业。always -执行作业而不管先前阶段的作业状态如何。manual-手动执行作业在GitLab 8.10中已添加.delayed-一定时间后执行作业在GitLab 11.14中已添加。when非必须定义了job什么时候执行可以是on_success、on_failure、always和manualdependencies非必须定义了该job依赖哪一个job如果设置该项可以通过artifacts设置artifacts非必须工件在依赖项之间传递的东西类似cache但原理与cache不同cache非必须定义需要被缓存的文件、文件夹列表before_script非必须覆盖在作业之前执行的脚本或命令after_script非必须覆盖在作业之后执行的脚本或命令environment非必须定义让job完成部署的环境名称coverage非必须定义job设置代码覆盖率stages非必须定义pipeline的全部阶段stage阶段内所有任务并行执行全部执行成功开始下一阶段任务任何阶段内任意job执行失败都会导致pipeline失败所有stagejob执行成功后pipeline会显示pass。如果未定义stages则默认有build、test、deploy三个阶段如果未定义stage则默认test阶段rules非必须用于评估和确定作业的选定属性以及是否创建该作业。不能与only/except 一起使用include非必须允许此作业包括外部YAML文件。也可用include:localinclude:fileinclude:template和include:remote。interruptible非必须定义在通过新的运行使其冗余时是否可以取消作业。resource_group非必须限制作业并发。timeout非必须定义自定义作业级别的超时该超时优先于项目范围的设置。4. 编写说明.gitlab-ci.yml文件中指定了CI的触发条件、工作内容、工作流程编写和理解此文件是CI实战中最重要的一步该文件指定的任务内容总体构成了1个pipeline、1个pipeline包含不同的stage执行阶段、每个stage包含不同的具体job脚本任务。4.1. 配置文件说明4.2. Pipeline说明一个.gitlab-ci.yml文件触发后会形成一个pipeline任务流由gitlab-runner来运行处理pipeline中stage、job概念如下需要按照项目实际情况定义不同stage和job 自己绘制了一个流程示意图帮助理解:5. 示例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参考文献gitlab服务之gitlab-ci.yml配置文件详解-侯体宗的博客GitLab之gitlab-ci.yml配置文件最全参数解读 - 知乎Gitlab-CI使用及.gitlab-ci.yml配置入门 - 测试开发喵 - 博客园