在GitLab CI/CD中使用environment对部署环境进行管理

背景

每一个应用都在研发阶段都会有几套环境，开发环境，集成环境，测试环境，生成环境。对于不同的环境，CI/CD的处理方式可能有所不同。在GitLab CI/CD中，如果开发者想要快速查询某一个部署环境的部署历史，可以在流水线列表中，使用分支名称，触发用户，tag名称，以及流水线状态来进行搜索，如下图：

但如果开发者想要查询某一个部署环境的部署历史，在这种情况下，流水线的搜索是无法满足需要的。即使开发团队规定 特定分支部署特定环境。

environment关键词

解决部署环境管理的问题需要使用GitLab CI/CD关键词environment。使用它，开发者可以将一个作业设置为某一环境的部署作业，同一个环境的部署作业会被收集到一起，运行部署作业，或者停止作业都将触发一个钩子。开发者可以自定义执行相关业务逻辑。下图是一个部署环境的管理页面（ 本文环境为GitLab 14.1）

开发者可以通过UI页面自行创建 部署环境，也可以在一个作业中定义environment的值，

通过UI创建部署环境

点击上图的 New environment

填写环境名称，以及环境的访问路径。保存。

通过作业部署环境

deploy_test_env:
  script: echo 'deploy test env'
  environment:
    name: test
    url: https://fizzz.blog.csdn.net/

环境名称只能包含字母，数字，空格以及这些字符 -, _, /, $, {, }。
同一个环境的作业会被归纳到同一个环境中，通过UI页面，点击环境名称即可查看该环境下已经部署的作业，如下：

URL的作用

定义了 环境URL，开发者可以点击页面一个按钮来快捷地访问到部署环境。
下面是三处可以访问的按钮

第一处，environment列表

第二处 environment 详情

第三处 合并请求时

environment关键词除了name和url两个配置项外，还有on_stop，auto_stop_in， action，kubernetes， deployment_tier。
下面通过作者的实践结合官方文档，简单介绍一下各个配置项的作用

其他配置项

on_stop是用于定义一个在移除环境时触发的作业，它的值必须是一个同流水线，同环境的作业名称。表明在通过UI移除部署环境或者自动移除部署环境时 运行配置的作业。

auto_stop_in 配置项用于到期自动移除部署环境，如一天后，一周后

action配置项是用于定义当期作业是部署环境的动作，有三个值，start 默认值），prepare，stop。
start 表明当期作业是创建一个部署环境
prepare 准备部署环境
stop 停止部署环境 on_stop选择的作业必须配置 action: stop。

下面是一个例子大家可以参考一下

# 部署test环境，停止环境时运行clean_test_env作业
deploy_test_env:
  script: echo 'deploy test env'
  environment:
    name: test
    url: https://fizzz.blog.csdn.net/
    on_stop: clean_test_env

# 部署dev环境，一周后自动停止
deploy_dev_env:
  script: echo 'deploy test env'
  environment:
    name: test
    url: https://fizzz.blog.csdn.net/
    auto_stop_in: 1 week
   
# 停止test环境，停止环境的脚本需自行编写
clean_test_env:
  script: echo 'stop deploy and clean test env'
  when: manual
  environment:
    name: test
    action: stop

kubernetes 可以设置部署的Kubernetes集群命名空间，前提是当前项目已集成Kubernetes。

deployment_tier 用于设置的部署等级，没有太多意义。只是用于区分。常用等级有这些 production，staging，testing，development，other

后记

使用关键词environment可以帮助开发者快速管理部署环境，跟踪问题，极大地提高了开发体验。大家一点要学会哦。