用 GitLab 做 CI/CD 是什么感觉,太强了

标签: gitlab ci cd | 发表时间:2020-08-15 22:52 | 作者:玻璃樽
出处:http://weekly.dockone.io

GitLab CI/CD 是一个内置在 GitLab 中的工具,用于通过持续方法进行软件开发:
  • Continuous Integration(CI):持续集成
  • Continuous Delivery(CD):持续交付
  • Continuous Deployment(CD):持续部署


持续集成的工作原理是将小的代码块推送到 Git 仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中。

持续交付和部署相当于更进一步的 CI,可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

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

GitLab CI/CD 由一个名为 .gitlab-ci.yml 的文件进行配置,改文件位于仓库的根目录下。文件中指定的脚本由 GitLab Runner 执行。

GitLab CI/CD 介绍

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

它涉及到在每次小的迭代中就不断地构建、测试和部署代码更改,从而减少了基于已经存在 bug 或失败的先前版本开发新代码的机会。
  • Continuous Integration(持续集成),假设一个应用程序,其代码存储在 GitLab 的 Git 仓库中。开发人员每天都要多次推送代码更改。对于每次向仓库的推送,你都可以创建一组脚本来自动构建和测试你的应用程序,从而减少了向应用程序引入错误的机会。这种做法称为持续集成,对于提交给应用程序(甚至是开发分支)的每项更改,它都会自动连续进行构建和测试,以确保所引入的更改通过你为应用程序建立的所有测试,准则和代码合规性标准。
  • Continuous Delivery(持续交付),持续交付是超越持续集成的更进一步的操作。应用程序不仅会在推送到代码库的每次代码更改时进行构建和测试,而且,尽管部署是手动触发的,但作为一个附加步骤,它也可以连续部署。此方法可确保自动检查代码,但需要人工干预才能从策略上手动触发以必输此次变更。
  • Continuous Deployment(持续部署),与持续交付类似,但不同之处在于,你无需将其手动部署,而是将其设置为自动部署。完全不需要人工干预即可部署你的应用程序。


GitLab CI/CD 是如何工作的

为了使用GitLab CI/CD,你需要一个托管在 GitLab 上的应用程序代码库,并且在根目录中的 .gitlab-ci.yml 文件中指定构建、测试和部署的脚本。

在这个文件中,你可以定义要运行的脚本,定义包含的依赖项,选择要按顺序运行的命令和要并行运行的命令,定义要在何处部署应用程序,以及指定是否 要自动运行脚本或手动触发脚本。

为了可视化处理过程,假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。

一旦你已经添加了.gitlab-ci.yml到仓库中,GitLab 将检测到该文件,并使用名为 GitLab Runner 的工具运行你的脚本。该工具的操作与终端类似。

这些脚本被分组到 jobs,它们共同组成一个 Pipeline。一个最简单的 .gitlab-ci.yml 文件可能是这样的:
before_script:   
- apt-get install rubygems ruby-dev -y 

run-test: 
script: 
- ruby --version 6

before_script 属性将在运行任何内容之前为你的应用安装依赖,一个名为 run-test 的 job(作业)将打印当前系统的 Ruby 版本。二者共同构成了在每次推送到仓库的任何分支时都会被触发的 Pipeline(管道)。

GitLab CI/CD 不仅可以执行你设置的 job,还可以显示执行期间发生的情况,正如你在终端看到的那样:

为你的应用创建策略,GitLab 会根据你的定义来运行 Pipeline。你的管道状态也会由 GitLab 显示:

最后,如果出现任何问题,可以轻松地回滚所有更改:

基本 CI/CD 工作流程

一旦你将提交推送到远程仓库的分支上,那么你为该项目设置的 CI/CD 管道将会被触发。GitLab CI/CD 通过这样做:

  • 运行自动化脚本(串行或并行) 代码Review并获得批准
    • 构建并测试你的应用
    • 就像在你本机中看到的那样,使用 Review Apps 预览每个合并请求的更改 

  • 代码 Review 并获得批准
  • 合并 feature 分支到默认分支,同时自动将此次更改部署到生产环境
  • 如果出现问题,可以轻松回滚


通过 GitLab UI 所有的步骤都是可视化的 。

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

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

Verify:
  • 通过持续集成自动构建和测试你的应用程序
  • 使用 GitLab 代码质量(GitLab Code Quality)分析你的源代码质量
  • 通过浏览器性能测试(Browser Performance Testing)确定代码更改对性能的影响
  • 执行一系列测试,比如 Container Scanning,Dependency Scanning,JUnit tests
  • 用 Review Apps 部署更改,以预览每个分支上的应用程序更改


Package:
  • 用 Container Registry 存储 Docker 镜像
  • 用 NPM Registry 存储 NPM 包
  • 用 Maven Repository 存储 Maven artifacts
  • 用 Conan Repository 存储 Conan 包


Release:
  • 持续部署,自动将你的应用程序部署到生产环境
  • 持续交付,手动点击以将你的应用程序部署到生产环境
  • 用 GitLab Pages 部署静态网站
  • 仅将功能部署到一个 Pod 上,并让一定比例的用户群通过 Canary Deployments 访问临时部署的功能(PS:即灰度发布)
  • 在 Feature Flags 之后部署功能
  • 用 GitLab Releases 将发布说明添加到任意 Git tag
  • 使用 Deploy Boards 查看在 Kubernetes 上运行的每个 CI 环境的当前运行状况和状态
  • 使用 Auto Deploy 将应用程序部署到 Kubernetes 集群中的生产环境


使用 GitLab CI/CD,还可以:
  • 通过 Auto DevOps 轻松设置应用的整个生命周期
  • 将应用程序部署到不同的环境
  • 安装你自己的 GitLab Runner
  • Schedule pipelines
  • 使用安全测试报告(Security Test reports)检查应用程序漏洞


GitLab CI/CD 快速开始

.gitlab-ci.yml 文件告诉 GitLab Runner 要做什么。一个简单的管道通常包括三个阶段:build、test、deploy

管道在 CI/CD > Pipelines 页面。

创建一个 .gitlab-ci.yml 文件

通过配置 .gitlab-ci.yml 文件来告诉 CI 要对你的项目做什么。它位于仓库的根目录下。

仓库一旦收到任何推送,GitLab 将立即查找 .gitlab-ci.yml 文件,并根据文件的内容在 Runner 上启动作业。

下面是一个 Ruby 项目配置例子:
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

上面的例子中,定义里两个作业,分别是 rspec 和 rubocop,在每个作业开始执行前,要先执行 before_script 下的命令。

推送 .gitlab-ci.yml 到 GitLab

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

配置一个 Runner

在 GitLab 中,Runner 运行你定义在 .gitlab-ci.yml 中的作业(job)。

一个 Runner 可以是一个虚拟机、物理机、Docker 容器,或者一个容器集群。

GitLab 与 Runner 之间通过 API 进行通信,因此只需要 Runner 所在的机器有网络并且可以访问 GitLab 服务器即可。

你可以去 Settings ➔ CI/CD 看是否已经有 Runner 关联到你的项目,设置 Runner 简单又直接 。

查看 Pipeline 和 jobs 的状态

在成功配置 Runner 以后,你应该可以看到你最近的提交的状态。

为了查看所有 jobs,你可以去 Pipelines ➔ Jobs 页面。

通过点击作业的状态,你可以看到作业运行的日志。

回顾一下:
  • 首先,定义 .gitlab-ci.yml 文件。在这个文件中就定义了要执行的 job 和命令
  • 接着,将文件推送至远程仓库
  • 最后,配置 Runner,用于运行 job


Auto DevOps

Auto DevOps 提供了预定义的 CI/CD 配置,使你可以自动检测,构建,测试,部署和监视应用程序。借助 CI/CD 最佳实践和工具,Auto DevOps 旨在简化成熟和现代软件开发生命周期的设置和执行。

借助 Auto DevOps,软件开发过程的设置变得更加容易,因为每个项目都可以使用最少的配置来完成从验证到监视的完整工作流程。只需推送你的代码,GitLab 就会处理其他所有事情。这使得启动新项目更加容易,并使整个公司的应用程序设置方式保持一致。

下面这个例子展示了如何使用 Auto DevOps 将 GitLab.com 上托管的项目部署到 Google Kubernetes Engine。

示例中会使用 GitLab 原生的 Kubernetes 集成,因此不需要再单独手动创建 Kubernetes 集群。

本例将创建并部署一个从 GitLab 模板创建的应用。

从 GitLab 模板创建项目

在创建 Kubernetes 集群并将其连接到 GitLab 项目之前,你需要一个 Google Cloud Platform 帐户。

下面使用 GitLab 的项目模板来创建一个新项目。

给项目起一个名字,并确保它是公有的。

从 GitLab 模板创建 Kubernetes 集群

点击 Add Kubernetes cluster 按钮,或者 Operations > Kubernetes。



安装 Helm,Ingress 和 Prometheus。

启用 Auto DevOps(可选)

Auto DevOps 默认是启用的。

导航栏 Settings > CI/CD > Auto DevOps。

勾选 Default to Auto DevOps pipeline。

最后选择部署策略。

一旦你已经完成了以上所有的操作,那么一个新的 Pipeline 将会被自动创建。为了查看 Pipeline,可以去 CI/CD > Pipelines。

部署应用

到目前为止,你应该看到管道正在运行,但是它到底在运行什么呢?

管道内部分为4个阶段,我们可以查看每个阶段有几个作业在运行,如下图:

构建 -> 测试 -> 部署 -> 性能测试。

现在,应用已经成功部署,让我们通过浏览器查看。

首先,导航到 Operations > Environments。

在 Environments 中,可以看到部署的应用的详细信息。在最右边有三个按钮,我们依次来看一下:

第一个图标将打开在生产环境中部署的应用程序的 URL。这是一个非常简单的页面,但重要的是它可以正常工作!

紧挨着第二个是一个带小图像的图标,Prometheus 将在其中收集有关 Kubernetes 集群以及应用程序如何影响它的数据(在内存/ CPU使用率,延迟等方面)。

第三个图标是Web终端,它将在运行应用程序的容器内打开终端会话。

Examples

使用 GitLab CI/CD 部署一个 Spring Boot 应用。

示例 .gitlab-ci.yml
image: java:8  

stages:
- build
- deploy

before_script:
- chmod +x mvnw

build:
stage: build
script: ./mvnw package
artifacts:
 paths:
   - target/demo-0.0.1-SNAPSHOT.jar

production:
stage: deploy
script:
- curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx
- ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io
- ./cf push
only:
- master


原文链接: https://www.cnblogs.com/cjsblog/p/12256843.html,作者:废物大师兄

相关 [gitlab ci cd] 推荐:

用 GitLab 做 CI/CD 是什么感觉,太强了

- - DockOne.io
GitLab CI/CD 是一个内置在 GitLab 中的工具,用于通过持续方法进行软件开发:. Continuous Integration(CI):持续集成. Continuous Delivery(CD):持续交付. Continuous Deployment(CD):持续部署. 持续集成的工作原理是将小的代码块推送到 Git 仓库中托管的应用程序代码库中,并且每次推送时,都要运行一系列脚本来构建、测试和验证代码更改,然后再将其合并到主分支中.

有赞零售移动 CI/CD 实践

- - IT瘾-dev
点击关注“有赞coder”. 随着有赞零售业务的蓬勃发展,为了尽早交付有价值的应用满足客户需求,我们采用了敏捷开发的模式,快速拥抱变化的同时保持竞争优势. 从 2019 年起,零售客户端的发版周期更改为每周一次,这对移动端的持续集成与交付提出更高的要求. 如何根据现有的团队规模,在有限的资源下,快速搭建稳定可靠的持续集成与交付系统,我们有了自己的实践与思考.

GitLab-CI:从零开始的前端自动化部署

- - DockOne.io
gitlab-ci&&自动化部署工具的运行机制. 1、通过在项目根目录下配置.gitlab-ci.yml文件,可以控制CI流程的不同阶段,例如install/检查/编译/部署服务器. GitLab平台会扫描.gitlab-ci.yml文件,并据此处理CI流程. 2、CI流程在每次团队成员push/merge后之后触发.

Trendyol 搜索团队的CI/CD流水线结构

- - DockOne.io
本文将描述在Trendyol的搜索团队中,我们的流水线(pipeline)是如何设计的,以及我们的CI/CD都有哪些特点:. • 为QA和开发团队创建同步分支. • 用Sonar分析构建项目. • Sonar质量门状态检查. • QA同步功能流水线. • 为测试部署一个基于特性的容器.

恶搞CD封面

- Weiye - 超现实创意网
当你热衷于某一项事物时,收藏也许会慢慢变成浮云,如何从中获取对生命的重新思考才是大势所趋. 著名的DJ兼作曲家Christian Marclay手上拥有无数张CD唱片,一颗不羁的心促使他发现了这些唱片封面之间的“因果联系”,于是我们久仰的迈克也能穿上热辣的透视裤,被山寨化的PS一番.

CD之父大贺典雄去世

- aviot - Solidot
前索尼公司CEO大贺典雄因多脏器功能衰竭于4月23日去世,终年81岁. 大贺典雄从1982年到1995年领导索尼,期间的重要决策包括耗资34亿美元收购哥伦比亚唱片公司;作为一位前歌唱家,他坚持CD的直径应设计为12厘米,能播放74分钟长的音乐——恰好能收录全首贝多芬第九交响曲.

废弃物之美,CD成海

- Y - 果壳网 guokr.com - 果壳网
在这个高速发展的数字时代,光盘已经不再是人们存储信息的首选. 你已经多久没有打开CD机,塞入一张CD,静静地放完整张专辑了. 现在许多人都能随意翻出一堆弃置许久的CD,它们的盘面都已刮花,不能再被机器读取. 可是,那些曾经挚爱的CD现在只能被尘封在记忆里了吗. 当然不是,两个法国人告诉我们,废旧CD也可以创造艺术美.

Jenkins: 使用Jenkins搭建持续集成(CI)环境

- - CSDN博客研发管理推荐文章
首先从官网 http://jenkins-ci.org/下载 Java Web Archive (.war). 例如我保存到 D:\jenkins\jenkins.war. 运行Jenkins需要JRE的支持Java5 or later. 默认会运行在8080端口,正常启动完成如下图. 我们可以在浏览器输入127.0.0.1:8080来查看,如图我们的Jenkins已经跑起来了.

从Gitlab误删除数据库想到的

- - 酷 壳 – CoolShell
昨天,Gitlab.com发生了一个大事,某同学误删了数据库,这个事看似是个低级错误,不过,因为Gitlab把整个过程的细节都全部暴露出来了,所以,可以看到很多东西,而对于类似这样的事情,我自己以前也干过,而在最近的两公司中我也见过(Amazon中见过一次,阿里中见过至少四次),正好通过这个事来说说一下自己的一些感想和观点吧.

从Gitlab误删数据库事件,说一说IT审计的那些事儿

- - 钛媒体:网罗天下创新事
就在两天前,《Gitlab误删300GB数据,备份失效后直播抢救》、《Gitlab不小心删除了数据库导致网站下线》霸屏了科技新闻的头条. 整个事件的回顾,Gitlab 第一时间放到了 Google Doc 上,并在 Twitter 上对事件的处置状态进行实时更新,后来索性在 Youtube上 开了频道直播恢复进程,目前网站已经恢复了正常,不幸的是,Gitlab 还是丢掉了差不多6个小时的数据.