GitLab CI/CD的官译【原】

CI / CD方法简介

软件开发的持续集成基于自动执行脚本，以最大限度地减少在开发应用程序时引入错误的可能性。从新代码的开发到部署，它们需要较少的人为干预甚至根本不需要干预。

它涉及在每次小迭代中不断构建，测试和部署代码更改，从而减少基于有缺陷或失败的先前版本开发新代码的风险。

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

 

持续集成（Continuous Integration, 简称CI）

考虑一个应用程序，其代码存储在GitLab中的Git存储库中。开发人员每天多次推送代码更改。对于每次推送到存储库，您都可以创建一组脚本来自动构建和测试应用程序，从而减少向应用程序引入错误的可能性。

这种做法被称为持续集成 ; 对于提交给应用程序的每个更改 - 甚至是开发分支 - 它都是自动且连续地构建和测试的，确保所引入的更改通过您为应用程序建立的所有测试，指南和代码合规性标准。

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

 

持续交付（Continuous Delivery，简称CD）

持续交付是持续集成的一个步骤。您的应用程序不仅在推送到代码库的每个代码更改时都构建和测试，而且，作为一个额外的步骤，它也会连续部署，尽管部署是手动触发的。

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

 

持续部署 （Continuous Deployment， 简称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管道pipeline。通过这样运行GitLab CI / CD：

  • 运行自动脚本（顺序或并行）到：
    • 构建并测试您的应用。
    • 使用“评论应用”预览每个合并请求的更改，如您所见localhost。

一旦您对实施感到满意：

  • 让您的代码经过审核和批准。
  • 将功能分支合并到默认分支。
    • GitLab CI / CD会自动将更改部署到生产环境中。
  • 最后，如果出现问题，您和您的团队可以轻松地将其回滚。

GitLab工作流程示例

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

 

深入了解CI / CD基本工作流程

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

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

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

  1. 验证：
  2. 套餐：
  3. 发布：
    • 持续部署，自动将您的应用部署到生产环境。
    • 持续交付，手动点击将您的应用部署到生产环境。
    • 使用GitLab Pages部署静态网站。
    • 只向部分pod提供功能，并允许一部分用户群使用Canary Deployments访问临时部署的功能。
    • 在功能标志后面部署功能。
    • 使用GitLab Releases向任何Git标签添加发行说明。
    • 查看使用部署板在Kubernetes上运行的每个CI环境的当前运行状况和状态。
    • 使用Auto Deploy将应用程序部署到Kubernetes集群中的生产环境。

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

要查看所有CI / CD功能，请导航回CI / CD索引。

 观看视频GitLab CI Live Demo，深入了解GitLab CI / CD。

首次设置GitLab CI / CD

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

本文档介绍了GitLab CI / CD在GitLab页面范围内的概念，用于部署静态网站。虽然它适用于想要从头开始编写自己的Pages脚本的用户，但它也可以作为GitLab CI / CD设置过程的介绍。它涵盖了编写CI / CD配置文件的第一个常规步骤，因此我们建议您通读它以了解GitLab的CI / CD逻辑，并学习如何为任何应用程序编写自己的脚本（或调整现有脚本）。

有关GitLab的CI / CD配置选项的深入视图，请查看 .gitlab-ci.yml完整参考。

GitLab CI / CD入门

注意： 从8.0版开始，GitLab 持续集成（CI）完全集成到GitLab本身，并在所有项目中默认启用。
注意： 请记住，只有项目维护者和管理员用户才有权访问项目的设置。

GitLab提供持续集成服务。如果 将.gitlab-ci.yml文件添加到存储库的根目录，并将GitLab项目配置为使用Runner，则每次提交或推送都会触发CI 管道。

该.gitlab-ci.yml文件告诉GitLab执行者该做什么。默认情况下，它运行有三个流水线阶段：build，test，和deploy。你不需要使用所有三个阶段; 没有工作的阶段被忽略了。

如果一切运行正常（没有非零返回值），您将获得与提交相关联的漂亮绿色复选标记。这样可以在查看代码之前轻松查看提交是否导致任何测试失败。

大多数项目使用GitLab的CI服务来运行测试套件，以便开发人员在破坏某些内容时立即获得反馈。

使用持续交付和持续部署将测试代码自动部署到登台和生产环境的趋势越来越明显。

简而言之，具有工作CI所需的步骤可归纳为：

  1. 添加.gitlab-ci.yml到存储库的根目录
  2. 配置一个Runner

从那时起，在每次推送到Git存储库时，Runner将自动启动管道，管道将显示在项目的Pipelines页面下。

本指南假设您拥有：

  • 一个正在运行的版本8.0 + r的GitLab实例或正在使用 GitLab.com。
  • GitLab中的一个项目，您希望使用CI。
  • 维护者或所有者访问项目

让我们把它分解成碎片并努力解决GitLab CI难题。

创建.gitlab-ci.yml文件

在您创建之前，.gitlab-ci.yml让我们先简要解释一下这是什么。

什么是 .gitlab-ci.yml

.gitlab-ci.yml您可以在该文件中配置CI对项目执行的操作。它位于存储库的根目录中。

在对存储库的任何推送中，GitLab将根据文件的内容查找.gitlab-ci.yml 文件并在Runners上启动作业。

因为.gitlab-ci.yml在存储库中并且受版本控制，旧版本仍然可以成功构建，分支可以轻松地使用CI，分支可以具有不同的管道和作业，并且您具有CI的单一事实来源。您可以.gitlab-ci.yml 在我们的博客中详细了解我们使用它的原因。

创建一个简单的.gitlab-ci.yml文件

注意： .gitlab-ci.yml是一个YAML文件，因此您必须特别注意缩进。始终使用空格，而不是制表符。

您需要创建一个.gitlab-ci.yml在存储库的根目录中命名的文件。下面是Ruby on Rails项目的示例。

image: "ruby:2.5"

before_script:
  - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
  - ruby -v
  - which ruby
  - gem install bundler --no-document
  - bundle install --jobs $(nproc)  "${FLAGS[@]}"

rspec:
  script:
    - bundle exec rspec

rubocop:
  script:
    - bundle exec rubocop

这是最简单的配置，适用于大多数Ruby应用程序：

  1. 使用要执行的不同命令定义两个作业rspec和rubocop（名称是任意的）。
  2. 在每个作业之前，before_script执行定义的命令。

该.gitlab-ci.yml文件定义了具有运行方式和时间限制的作业集。该工作被定义为一个名称顶层元素（在我们的情况rspec和rubocop），并总是要包含script关键词。作业用于创建作业，然后由执行者选择并在执行者的环境中执行。

重要的是每项工作都是相互独立运作的。

如果要检查.gitlab-ci.yml项目是否有效，/-/ci/lint项目命名空间的页面下会有一个Lint工具。您还可以在CI / CD下找到“CI Lint”按钮进入此页面➔管道和 管道➔项目中的作业。

有关更多信息和完整.gitlab-ci.yml语法，请阅读 .gitlab-ci.yml上的参考文档。

 

 

推.gitlab-ci.yml送到GitLab

创建之后.gitlab-ci.yml，您应该将其添加到Git存储库并将其推送到GitLab。

git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master

现在，如果您转到“ 管道”页面，您将看到管道处于待处理状态。

注意： 如果您有一个GitLab来自的镜像存储库，您可能需要在项目的设置>存储库>从远程存储库中提取>镜像更新的触发管道中启用管道触发 。

您也可以转到“ 提交”页面，注意提交SHA旁边的小暂停图标。

新提交待处理

单击它，您将被定向到该特定提交的作业页面。

单个提交作业页面

请注意，有一个挂起的作业以我们写的内容命名 .gitlab-ci.yml。“卡住”表示尚未为此作业配置Runner。

下一步是配置一个Runner，以便它选择挂起的作业。

配置Runner

在GitLab中，Runners运行您定义的作业.gitlab-ci.yml。Runner可以是虚拟机，VPS，裸机，docker容器甚至是容器集群。GitLab和Runners通过API进行通信，因此唯一的要求是Runner的机器可以访问GitLab服务器。

Runner可以特定于某个项目，也可以在GitLab中提供多个项目。如果它服务于所有项目，则称为共享运行者。

在Runners文档中查找有关不同Runners的更多信息 。

您可以通过转到设置➔CI/ CD找到是否为您的项目分配了任何执行者 。设置一个Runner既简单又直接。由GitLab支持的官方Runner是用Go编写的，其文档可以在https://docs.gitlab.com/runner/找到。

要获得功能性Runner，您需要执行以下两个步骤：

  1. 安装它
  2. 配置它

按照上面的链接设置您自己的Runner或使用Shared Runner，如下一节所述。

设置好Runner后，您应该按照设置➔CI/ CD在项目的Runners页面上看到它。

激活的跑步者

共享执行者

如果您使用GitLab.com，您可以使用 GitLab Inc.提供的共享执行者。

这些是在GitLab的基础架构上运行的特殊虚拟机，可以构建任何项目。

要启用共享运行器，您必须转到项目的 设置➔CI/ CD，然后单击启用共享运行器。

阅读共享执行者的更多信息。

查看管道和作业的状态

成功配置Runner后，您应该会看到上次提交的状态从挂起更改为运行，成功或失败。

您可以转到项目的“ 管道”页面来查看所有管道。

提交状态

或者您可以通过管道➔工作页面查看所有工作。

提交状态

通过单击作业的状态，您将能够看到该作业的日志。这对于诊断工作失败或行为与预期不同的原因非常重要。

构建日志

您还可以在GitLab的各个页面中查看任何提交的状态，例如提交和合并请求。

例子

访问示例README，查看使用各种语言的GitLab CI的示例列表。

GitLab CI / CD示例

此页面包含各种示例的链接，这些示例可帮助您了解如何针对特定用例实施GitLab CI / CD。

示例有多种形式。作为一个集合：

  • .gitlab-ci.yml 在GitLab中维护的模板文件。当您通过UI创建新文件时，GitLab将为您提供选择其中一个模板的选项。这将允许您快速引导项目以进行CI / CD。如果您缺少您喜欢的编程语言或框架，我们会非常乐意通过向.gitlab-ci.yml此项目发送新的合并请求来提供帮助。
  • 包含各种语言的示例项目的存储库。您可以根据自己的需要进行分叉和调整。项目包括多项目管道的演示以及使用由nginx提供的静态站点的评论应用程序。
  • 下面列出的示例和其他资源。

CI / CD示例

下表列出了本节中包含的分步教程的示例。

用例资源
浏览器性能测试 使用Sitespeed.io容器进行浏览器性能测试。
Clojure的 使用GitLab CI / CD测试Clojure应用程序。
使用Dpl进行部署 使用dpl的部署工具。
酏 使用GitLab CI / CD测试Phoenix应用程序。
端到端测试 使用GitLab CI / CD和WebdriverIO进行端到端测试。
游戏开发 DevOps和Game Dev with GitLab CI / CD。
GitLab页面 有关部署静态站点的完整示例，请参阅GitLab Pages文档。
带Spring Boot的Java 使用GitLab CI / CD将Spring Boot应用程序部署到Cloud Foundry。
Java与Maven 如何使用GitLab CI / CD将Maven项目部署到Artifactory。
PHP with PHPunit，atoum 测试PHP项目。
PHP与NPM，SCP 通过GitLab CI / CD中的SCP部署运行Composer和NPM脚本。
PHP与Laravel，Ennvoy 使用GitLab CI / CD和Envoy测试和部署Laravel应用程序。
Heroku上的Python 使用GitLab CI / CD测试和部署Python应用程序。
Ruby on Heroku 使用GitLab CI / CD测试和部署Ruby应用程序。
Heroku上的Scala 测试Scala应用程序并将其部署到Heroku。

贡献的例子

欢迎捐款！您可以通过发送包含该语言指南的合并请求来帮助您喜爱的编程语言用户和GitLab。您可能想申请GitLab社区作家计划 ，以便为GitLab撰写完整的文章而获得报酬。

将模板添加到GitLab安装中

额外费用

如果您希望为团队提供自己管理的GitLab实例的自定义示例和模板，GitLab管理员可以指定一个实例模板存储库，其中包含特定于您的企业的示例和模板。

其他资源

本节提供了更多资源，可帮助您熟悉GitLab CI / CD的各种用途。请注意，较旧的文章和视频可能无法反映最新GitLab版本的状态。

云中的CI / CD

有关为基于云的环境设置GitLab CI / CD的示例，请参阅：

另请参阅以下视频概述：

客户故事

有关GitLab CI / CD的一些客户体验，请参阅：

入门

有关帮助您入门的示例，请参阅：

实施GitLab CI / CD

有关已实施GitLab CI / CD的其他人的示例，请参阅：

从第三方CI工具迁移到GitLab

将GitLab CI / CD与其他系统集成

要了解如何将GitLab CI / CD与第三方系统集成，请参阅：

移动开发

有关使用GitLab CI / CD进行移动应用程序开发的帮助，请参阅：

 
---
待续
posted @ 2019-07-05 16:24  sunsky303  阅读(1499)  评论(0)  编辑  收藏  举报
显示搜索