GitLab CI/CD

https://segmentfault.com/a/1190000010442764

GitLab CI / CD是GitLab内置的工具，用于通过连续方法进行软件开发：

软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。

它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的机会。

此方法有三种主要方法，每种方法都将根据最适合您的策略的方式进行应用。

持续集成（CI）：持续集成的工作原理是将小的代码块推送到Git存储库中托管的应用程序代码库中，并且每次推送时，都要运行脚本管道来构建，测试和验证代码更改，然后再将其合并到主分支中。
连续交付（CD）
持续部署（CD）
：持续交付和部署包括进一步的CI，可在每次推送到存储库默认分支时将应用程序部署到生产环境。

这些方法使您可以在开发周期的早期发现错误和错误，从而确保部署到生产环境的所有代码均符合为应用程序建立的代码标准。

持续集成CI
考虑一个应用程序，其代码存储在GitLab的Git存储库中。开发人员每天都要多次推送代码更改。对于每次向存储库的推送，您都可以创建一组脚本来自动构建和测试您的应用程序，从而减少了向应用程序引入错误的机会。这种做法被称为持续集成；对于提交给应用程序（甚至是开发分支）的每个更改，它都会自动连续地构建和测试，以确保所引入的更改能够通过您为应用程序建立的所有测试，准则和代码合规性标准。

GitLab本身就是使用持续集成作为软件开发方法的一个示例。对于项目的每一次推送，都有一组检查代码的脚本。

持续交付CD
持续交付是超越持续集成的一步。您的应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试，而且，作为附加步骤，即使部署是手动触发的，也可以连续部署。

此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。

持续部署CD
与持续交付类似，持续部署也是超越持续集成的又一步。区别在于，您无需将其手动部署，而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。

GitLab CI / CD简介
GitLab CI / CD是GitLab内置的功能强大的工具，它使您可以将所有连续方法（连续集成，交付和部署）应用于软件，而无需第三方应用程序或集成。

GitLab CI / CD如何工作
要使用GitLab CI / CD，您需要做的是托管在Git存储库中的应用程序代码库，并.gitlab-ci.yml在存储库根路径中名为的文件中指定构建，测试和部署脚本。

在此文件中，您可以定义要运行的脚本，定义包含和缓存依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在何处部署应用程序，以及指定是否将要自动运行脚本或手动触发任何脚本。熟悉GitLab CI / CD后，您可以在配置文件中添加更多高级步骤。

要将脚本添加到该文件，您需要按照适合您的应用程序并符合您要执行的测试的顺序来组织它们。为了可视化该过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

将.gitlab-ci.yml配置文件添加到存储库后，GitLab将检测到它并使用名为GitLab Runner的工具运行脚本，该工具的工作原理与终端类似。

这些脚本被分组为作业，它们共同组成了一个管道。.gitlab-ci.yml文件的简约示例可以包含：

before_script:
  - apt-get install rubygems ruby-dev -y

run-test:
  script:
    - ruby --version

该before_script属性将在运行任何内容之前为您的应用程序安装依赖项，并且名为 的作业run-test将打印当前系统的Ruby版本。它们都组成了在每次推送到存储库的任何分支时触发的管道。

GitLab CI / CD不仅执行您已设置的作业，而且还向您显示执行期间发生的情况，就像您在终端中看到的那样：

您为您的应用程序创建策略，GitLab根据您定义的内容为您运行管道。您的管道状态也会由GitLab显示：

最后，如果出现任何问题，您可以轻松 回滚所有更改：

基本CI / CD工作流程
考虑以下示例，以了解GitLab CI / CD如何适合通用开发工作流程。

假设您已在一个问题中讨论了代码实现，并在本地进行了建议的更改。将提交推送到GitLab中的远程存储库中的功能分支后，将触发为您的项目设置的CI / CD管道。这样，GitLab CI / CD：

• 运行自动化脚本（顺序或并行）以：
  1.构建并测试您的应用。
  2.就像您在中看到的那样，使用Review Apps预览每个合并请求的更改localhost。

对实施感到满意后：

• 让您的代码得到审查和批准。

• 将功能分支合并到默认分支。
  1.GitLab CI / CD将您的更改自动部署到生产环境。

• 最后，如果出现问题，您和您的团队可以轻松地将其回滚。

GitLab工作流程示例

GitLab CI / CD可以做更多的事情，但是此工作流程体现了GitLab跟踪整个过程的能力，而无需使用外部工具来交付软件。而且，最有用的是，您可以通过GitLab UI可视化所有步骤。

深入了解CI / CD基本工作流程
如果我们深入研究基本工作流程，则可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示。

深入研究基本CI / CD工作流程:

如果您从左到右查看图像，则会根据每个阶段（验证，打包，发布）看到GitLab中的一些可用功能。

1. 验证：

1.通过持续集成自动构建和测试您的应用程序。
2.使用GitLab代码质量分析您的源代码质量。
3.使用浏览器性能测试确定代码更改对浏览器性能的影响。
4.使用负载性能测试确定代码更改对服务器性能的影响。
5.执行一系列测试，例如容器扫描 ，依赖扫描 和JUnit测试。
6.使用Review Apps部署更改，以预览每个分支上的应用程序更改。

2. 包：

1.使用Container Registry存储Docker映像。
2.使用NPM Registry存储NPM软件包。
3.Maven存储库存储Maven工件。
4.将Conan软件包存储在Conan仓库中。

3. 发布：

1.持续部署，自动将您的应用程序部署到生产环境。
2.连续交付，手动单击以将您的应用程序部署到生产环境。
3.使用GitLab Pages部署静态网站。
4.仅将功能部件运送到一部分Pod中，并让一定比例的用户群通过Canary Deployments访问临时部署的功能部件。
5.在功能标记后面部署功能。
6.使用GitLab Releases向任何Git标签添加发行说明。
7.使用部署板查看Kubernetes上运行的每个CI环境的当前健康和状态。
8.使用Auto Deploy将应用程序部署到Kubernetes集群中的生产环境。

使用GitLab CI / CD，您还可以：

1.通过Auto DevOps轻松设置应用程序的整个生命周期。
2.将您的应用程序部署到不同的环境。
3.安装您自己的GitLab Runner。
4.计划管道。
5.使用“ 安全测试”报告检查应用程序漏洞。

首次设置GitLab CI / CD
要开始使用GitLab CI / CD，您需要熟悉.gitlab-ci.yml配置文件的语法及其属性。

GitLab CI / CD由.gitlab-ci.yml位于存储库根目录的一个文件配置。该文件创建一个管道，该管道运行以更改存储库中的代码。管道包含一个或多个顺序运行的阶段，每个阶段可以包含一个或多个并行运行的作业。这些作业（或脚本）由GitLab Runner代理执行。

开始构建之前YAML 文件定义了一系列带有约束说明的任务。这些任务都是以任务名开始并且至少要包含script 部分。

job1:
  script: "execute-script-for-job1"
  
job2:
  script: "execute-script-for-job2"

这就是一个最简单且带有俩个独立任务的CI配置，每个任务分别执行不同的命令。

script 可以直接执行系统命令（./configure;make;make install）或者是直接执行脚本（test.sh）。

任务是由Runners 接管并且由服务器中runner 执行，每一个任务的执行过程都是独立运行的。

（.gitlab-ci.yml 详细的配置）
https://segmentfault.com/a/1190000010442764