7.1 声明部署环境

1. 介绍

在准备将软件投入大众使用之前，软件开发过程需要许多阶段。

例如：

• 开发代码
• 测试代码
• 部署到测试或暂存环境

GitLab CI/CD 不仅能够测试或构建项目，还可以在集成架构中部署它们，并提供一种跟踪部署的方式的额外好处。换句话说，您将始终知道服务器当前正在部署或已经部署了什么。

重要的是要知道：

• 环境就像您的 CI 作业的标签，描述了代码的部署位置。
• 部署是在作业将代码版本部署到环境时创建的，因此，每个环境都可以有一个或多个部署。

2. 定义环境名称和 URL

2.1 定义静态环境

定义静态环境有两种方式：

• GitLab UI
• 使用 gitlab.ci.yml

(1) 使用 GitLab UI

//.gitlab-ci.yml

stages:
  - test
  - build
  - deploy
test:
  tags:
    - host20133-docker
  stage: test
  script: echo "Running tests"
build:
  tags:
    - host20133-docker
  stage: build
  script: echo "Building the app"
deploy:
  stage: deploy
  tags:
    - host20133-docker
  script:
    - export
  environment:
    name: dev

(2) 使用 .gitlab-ci.yml

stages:
  - test
  - build
  - deploy
test:
  tags:
    - host20133-docker
  stage: test
  script: echo "Running tests"
build:
  tags:
    - host20133-docker
  stage: build
  script: echo "Building the app"
deploy:
  stage: deploy
  tags:
    - host20133-docker
  script:
    - export
  environment:
    name: stage
    url: http://stage.xiodi.cn

2.2 配置动态环境

当部署到“稳定”的环境(如暂存或生产环境)时，常规静态环境是很好的选择。

但是，对于 master 环境以外的分支环境，可以使用动态环境。动态环境使动态创建环境成为可能,并且我们也还可以使用分组类似环境。

stages:
  - test
  - build
  - deploy
test:
  tags:
    - host20133-docker
  stage: test
  script: echo "Running tests"
build:
  tags:
    - host20133-docker
  stage: build
  script: echo "Building the app"
deploy_review:
  stage: deploy
  tags:
    - host20133-docker
  script:
    - export
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://${CI_ENVIRONMENT_SLUG}.xiodi.cn

2.3 查看环境 URL

该环境 URL 暴露于 GitLab 的几个地方。

• 合并请求
• 环境视图
• 部署视图

//合并请求

//环境视图

//部署视图

3. 环境的操作

3.1 停止环境

当多个开发人员同时在一个项目上工作时，通常会使用此方法，每个开发人员都将推入自己的分支，从而创建了许多动态环境。

停止环境：

• 从可用环境移动到停止环境列表中
• 执行 on_stop 操作（如果已定义）

[info]注意：从GitLab 8.14开始，删除动态环境的关联分支后，它们会自动停止。

（1）手动停止环境

（2）手动停止环境并清理环境

stages:
  - test
  - build
  - deploy
test:
  tags:
    - host20133-docker
  stage: test
  script: echo "Running tests"
build:
  tags:
    - host20133-docker
  stage: build
  script: echo "Building the app"
deploy_review:
  stage: deploy
  tags:
    - host20133-docker
  script:
    - export
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://${CI_ENVIRONMENT_SLUG}.xiodi.cn
    on_stop: stop_review
stop_review:
  stage: deploy
  tags:
    - host20133-docker
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Remove review app"
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop

在作业 stop_review 中必须设置GIT_STRATEGY: none ，以便GitLab Runner在删除分支后不会尝试检出代码。

当您的环境中定义了停止动作时（通常在该环境描述了一个Review App时），当关联的分支被删除时，GitLab将自动触发停止动作。该stop_review作业必须与deploy_review on_stop 作业相同，以便环境自动停止。

（3）环境自动停止

GitLab 12.8 中引入。

您可以设置环境的到期时间，并在一定时间后自动将其停止。

stages:
  - test
  - build
  - deploy
test:
  stage: test
  script: echo "Running tests"
build:
  stage: build
  script: echo "Building the app"
deploy_review:
  stage: deploy
  tags:
    - docker-spring
  script:
    - echo "Deploy to develop"
    - export
  environment:
    name: deploy/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review
    auto_stop_in: 1 day
stop_review:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Remove review app"
  when: manual
  environment:
    name: deploy/$CI_COMMIT_REF_NAME
    action: stop

//部署后显示

[info] 时间格式：https://gitlabtest.xiodi.cn/help/ci/yaml/README.md#artifactsexpire_in

在这个示例中，每次作业都会更新过期时间，也就是说，如果您每次不到24小时就提交一次，就永远不会停止环境。

[info]注：由于资源限制，用于停止环境的后台工作器每小时仅运行一次。这意味着不会在指定的确切时间戳记下停止环境，而是在每小时的cron工作者检测到过期的环境时将其停止。