在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