了解：CICD 入门指北
简介持续集成持续部署Gitlab CICD如何使用 Gitlab CI/CDCICD 工作流.gitlab-ci.yml 文件结构stagesvariablesbefore_scripttest_stagestagescriptartifactsallow_failurebuild_stagewhenonlydeploy_stageARTIFACTORYhttps://www.jfrogchina.com/artifactory/的相关问题可以到网站了解下，我们是业内领域专业的平台，您如果有需要可以咨询，相信可以帮到您，值得您的信赖！
https://www.jfrogchina.com/wp-content/uploads/2017/12/Jfrog-Logo.svg
CICD 是 持续集成（Continuous Integration）和持续部署（Continuous Deployment）简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。
持续集成指在和向远程仓库 push 代码后，在这次提交合并入主分支前进行一系列测试，构建等流程。假设现在有个应用的代码存储在 gitlab 上，每天开发者都 push 很多次提交，针对每次 push，你可以创建一系列脚本进行自动测试，降低往应用里引入错误的概率。这就是持续集成，它可应用在包括开发分支在内的多个分支上。
持续部署在持续集成的基础上更进一步，指将推送指仓库默认分支的部署至产品环境。如果这部分需要手动触发，这就是一个持续交付（Continuous Delivery）环节。
Gitlab 内置了 CICD 工具，不需要使用第三方工具。
使用 Gitlab 的 CICD ，只需要在 Gitlab 的仓库的根目录中添加文件。
这个文件中，可以定义CICD 的各个环节，配置每个环节执行的命令，触发方式等。这个配置文件其实就是按照 YAML 规定了一些结构的 shell 脚本，里面的命令会在符合条件时逐一执行。一旦在仓库中添加这个文件，Gitlab 会检测到它并用名为工具执行它。每次触发的 CICD 会把配置中的脚划分为不同的 job，多个 job 组成一个 pipeline。最简单的文件可以包含：
其中属性会在执行任一脚本前预装一些需要的依赖（类似的方法），此后名为的脚本会显示当前系统的 ruby 版本。这两个步骤组成了一个 pipeline 会在这个仓库的每次push后执行。这行任务的执行情况也可以在 Gitlab 的对应页面上查看，就像在 Terminal 中看日志一样。
而每个 pipeline 的 job 的执行情况也可以在页面上查看
如果中途报错了，可以一键回滚
假设你在本地修改了一些代码以增加一些特性，当你把这些改动 push 到远程仓库的特性分支后，项目里设定的 CICD pipeline 就被触发了，一般流程如下：
运行自动脚本（串行或并行）：构建并测试应用在合并前 review 改动
上述流程如果没有问题就可以把改动合并入主分支，CD 会自动把它部署到产品中，如果发现了任何问题，还能一键回滚。
工作流程图如下：
该图简要显示了基本的工作流，想要了解 Gitlab CICD 的更多特请，请参阅
.gitlab-ci.yml 是指定了 CICD 相关配置的 YAML 文件。（YAML 是专门用来写配置文件的语言，简洁强大，和 python 一样用缩进代表层级，表达能力和 JSON 基本一致，但格式更方便。相关知识可以参考阮昱峰老师的。
一般而言，CICD 过程会包含如下最外层的 key：
: 定义整个 CICD pipeline 的数量和名称: 定义 CICD 流程中的一些环境变量: 在每个的执行前进行的命令集，一般是创建目录，打印 context 目录等操作，可类比的方法: 定义了一个的具体流程，可以在前面加上名称
下面通过一个例子进行一些讲解
例子中值为一个数组（p.s. 用 - 代表数组和 markdown 类似）。包含了三个 ，, ,分别实现自动测试，打包项目和部署。下方的必须在全局定义的内。
值为键值对象，为了后续的流程，此处定义了开发项目和部署项目的 namespace 和 repo_name。同 shell 类似，后续使用其值需要加上 $ 符号。定义的变量也有对应的作用域，定义在顶层就可以作为全局变量供所有使用，如果是一些特有的变量，就定义在内部。
值为数组，每一个元素其实就是一个 linux 命令，写的时候装作自己在写 shell 就好。该部分主要生成了后续构建需要的镜像标签，切换当前目录等。为了 debug 方便，这些变量最好打印。类似的，如果在完成后有一些时候操作，可以定义 。需要注意的是如果定义在顶层，内部的命令会在每个运行之前执行，如果某些需要特别的预操作，可以在 job 内部再配置一个对象，它会复写外部的全局预操作。
名为的的具体配置，一般是个复合对象。
对应的 ，如果有多个对应同一个 ，在执行时会并行执行这些 。
这个执行的命令，此处是进入的项目仓库目录，并且执行了一个 shell 脚本，这个脚本定义了执行项目的所有单元测试。一般建议如果要执行的命令过多，就把这些命令写成脚本放在项目内。CICD 流程直接执行这个脚本。
这个对象用来定义的产出，比如我们让产出一个 html 格式的报告，显示每个单元测试的执行情况（报告生成相关代码写在项目内）。 数组内的和分别定义报告的路径和产出场景。此处表示报告放置于根目录下，任何时候都要提供报告。设定正确后，就可以 Gitlab 的 pipline 页面上可以下载相关文件。
见名知意，如果值为 true，那么即使没通过测试，也可以执行后续的 .
该步骤在测试通过的基础上，把项目编译打包，方便后续部署。
此处的定义在内的顶层，值为 manual 表示其需要在 Gitlab 上手动触发（页面上点击按钮即可）。
指明了的执行场景，可以是分支名，表明只有 master 分支可以执行 ，如果要用排除法反向指定，可以用 。
所有的 key 现在你应该都了解了，这里不再赘述。这一步骤主要是将部署产品的服务器上的内容更新。 谢谢楼主，共同发展 过来看看的 看帖回帖是美德！:lol 有道理。。。 帮你顶下哈！！ 路过，学习下
页:
[1]