使用GitLab进行CI/CD简介
CI/CD方法论简介
软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的情况。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。
它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的情况。
持续集成
考虑一个应用程序，其代码存储在GitLab的Git存储库中。开发人员每天要多次推送代码更改。对于每次向存储库的推送，您都可以创建一组脚本来自动构建和测试您的应用程序，从而减少了向应用程序引入错误的情况。
这种做法被称为__持续集成__；对于提交给应用程序（甚至是开发分支）的每个更改，它都会自动连续地构建和测试，以确保所引入的更改通过您为应用程序建立的所有测试，准则和代码合规性标准。
GitLab本身就是使用持续集成作为软件开发的示例。对于项目的每一次推送，都有一组检查脚本的脚本。
持续交付
__持续交付__是超越持续集成的一步。应用程序不仅会在推送到代码库的每次代码更改是都进行构建和测试，而且作为附加步骤，尽管部署是手动触发的，但它仍会持续部署。
此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。
持续部署
类似于持续交付，__持续部署__也是超越持续集成的又一步。不同之处在于，无需将其手动部署，而是将其设置为自动部署。部署应用程序完全不需要人工干预。
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 的工具运行脚本，该工具的工作原理与终端类似。
这些脚本被分为__jobs__，它们共同组成了一个__pipeline__。.gitlab-ci.yml文件的简约示例可以包含：
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- python --version该before_script属性将在运行任何内容之前为应用程序安装依赖项，并且名为run-test 的__jobs__将打印当前系统的Python版本。它们两者都构成了在每次推送到存储库的任何分支时触发的__pipeline__。
GitLab CI / CD 不仅执行您设置的作业，而且还显示您在执行过程中发生的事情，就像在终端中看到的那样：
可以为app创建策略，GitLab根据您定义的内容为您运行管道。您的管道状态也会由GitLab显示：
最后，如果出现任何问题，都可以轻松回滚所有更改：
基本CI / CD工作流程
示例（了解GitLab CI / CD如何使用通用开发工作流程）
假设已在一个问题中讨论了代码实现，并在本地进行了建议的更改。将提交推送到GitLab中的远程存储库中的功能分支后，将触发为您的项目设置的 CI / CD管道。GitLab CI/CD将通过以下这样：
- 运行自动化脚本（顺序或并行）以：
- 构建并测试应用
- 会像你在本地看到的那样，使用审查应用程序预览每个合并请求的更改
当对实施感到满意后：
- 让你的代码得到审查和批准。
- 将功能分支合并到默认分支。
- GitLab CI / CD将您的更改自动部署到生产环境。
- 最后，如果出现问题，可以轻松的将其回滚
GitLab CI / CD可以做更多的事情，但是此工作流程体现了GitLab跟踪整个过程的能力，而无需使用外部工具来交付软件。而且，最有用的是，可以通过GitLab UI可视化所有步骤。
深入了解CI / CD基本工作流程
如果我们深入研究基本工作流程，则可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示。
如果从左至右查看图像，则会根据每个阶段（验证，打包，发布）看到GitLab中的一些可用功能。
- 验证：
- 通过持续集成自动构建和测试应用程序。
- 使用GitLab代码质量分析源代码质量。
- 使用浏览器性能测试确定代码更改对性能的影响。
- 执行一系列测试，例如容器扫描，依赖扫描和JUnit测试。
- 使用Review Apps部署更改，以预览每个分支上的应用程序更改。
- 包：
- 使用 Container Registry存储Docker映像。
- 使用NPM Registry存储NPM软件包
- 用Maven存储库存储Maven工件。
- 将Conan软件包存储在Conan仓库中。
- 发布
- 持续部署，自动将您的应用程序部署到生产环境。
- 持续交付，手动单击以将您的应用程序部署到生产环境。
- 使用GitLab Pages部署静态网站。
- 仅将feature运送到您的一部分吊舱中，并让一定比例的用户群通过Canary Deployments访问临时部署的feature
- 在 feature flags 后 部署 features
- 在使用 GitLab Releases 向任何Git 标签添加发行说明
- 使用 Deploy Boards 查看kubernetes上运行的每个 CI环境的当前健康和状态。
- 使用Auto Deploy将应用程序部署到Kubernetes集群中的生产环境
使用 GitLab CI / CD，还可以：
- 通过Auto DevOps轻松设置应用程序的整个生命周期。
- 将您的应用程序部署到不同的环境
- 安装自己的 GitLab Runner。
- Schedule pipelines
- 使用 "Security Test reports"检查应用程序漏洞。
首次设置 GitLab CI / CD
要使用GitLab CI / CD，需要熟悉.gitlab-ci.yml 配置文件的语法及其属性。
GitLab CI / CD管道配置参考
GitLab CI / CD pipelines 使用在每个项目中叫.gitlab-ci.yml的YAML配置文件。
该.gitlab-ci.yml文件定义了pipelines的结构和顺序，并确定：
- 使用GitLab Runner执行什么。
- 遇到特定条件时要做出什么决定。例如，当一个过程成功或失败时。
介绍
pipeline 配置从 jobs开始。jobs是.gitlab-ci.yml文件的最基本元素。
jobs是：
- 定义了约束，指出应在什么条件下执行它们。
- 具有任意名称的顶级元素，并且必须至少包含
script子句。 - 不限制可以定义多少个。
例如：
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"上面的示例是具有两个单独作业的最简单的CI/CD配置，其中每个job执行一个不同的命令。当然，命令可以在存储库中直接执行代码（./configure;make;make install）或运行脚本（test.sh）
Jobs被Runners拿到然后在Runner的环境中执行。重要的是，每个作业彼此独立运行。
验证.gitlab-ci.yml
每个GitLab CI 实例都有一个称为Lint的嵌入式调试工具，该工具可以验证.gitlab-ci.yml文件的内容。您可以在项目的命名空间的ci/lint页找到Lint。例如，https://gitlab.example.com/gitlab-org/project-123/-/ci/lint。
Jobs名称不可用
每个作业必须具有唯一的名称，但是有一些保留关键字名称不能用作job名称:
- image
- services
- stages
- types
- before_script
- after_script
- variables
- cache
- include
使用保留关键字
如果使用特定值（例如 true 或 false）时出现验证错误，请尝试执行以下操作：
- 引用他们。
- 将它们更改为其他形式。例如，
/bin/true。
实例
要实现GitLab CI/CD，需要做的第一件事是在网站的根目录下放置一个.gitlab-ci.yml配置文件。
该文件的实际作用是告诉GitLab Runner像在命令行中那样运行脚本。Runner充当终端。GitLab CI/CD告诉Runner运行哪些命令。两者都是内置在GitLab中的，无需设置任何内容即可使其正常工作。
假设现在又一个python网站，要在本地构建它，可以打开终端并运行python runserver.py。当然，在构建它之前，必须安装有项目的依赖项。
