背景
每一个应用都在研发阶段都会有几套环境，开发环境，集成环境，测试环境，生成环境。对于不同的环境，CI/CD的处理方式可能有所不同。在GitLab CI/CD中，如果开发者想要快速查询某一个部署环境的部署历史，可以在流水线列表中，使用分支名称，触发用户，tag名称，以及流水线状态来进行搜索，如下图：
在这里插入图片描述但如果开发者想要查询某一个部署环境的部署历史，在这种情况下，流水线的搜索是无法满足需要的。即使开发团队规定 特定分支部署特定环境。
environment关键词
解决部署环境管理的问题需要使用GitLab CI/CD关键词environment。使用它，开发者可以将一个作业设置为某一环境的部署作业，同一个环境的部署作业会被收集到一起，运行部署作业，或者停止作业都将触发一个钩子。开发者可以自定义执行相关业务逻辑。下图是一个部署环境的管理页面（ 本文环境为GitLab 14.1）
在这里插入图片描述开发者可以通过UI页面自行创建 部署环境，也可以在一个作业中定义environment的值，
通过UI创建部署环境
在这里插入图片描述点击上图的 New environment
在这里插入图片描述填写环境名称，以及环境的访问路径。保存。
通过作业部署环境
代码语言：yaml复制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。
下面是一个例子大家可以参考一下
代码语言：yaml复制# 部署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: stopkubernetes 可以设置部署的Kubernetes集群命名空间，前提是当前项目已集成Kubernetes。
deployment_tier 用于设置的部署等级，没有太多意义。只是用于区分。常用等级有这些 production，staging，testing，development，other
后记
使用关键词environment可以帮助开发者快速管理部署环境，跟踪问题，极大地提高了开发体验。大家一点要学会哦。
