| GitLab Docs

Help us learn about your current experience with the documentation. Take the survey.

stage: Verify group: Pipeline Execution info: 要确定与此页面关联的阶段/组的技术作家分配情况，请参阅 https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments description: 设置并使用评审应用，在合并前为测试变更创建临时环境。 title: 评审应用

层级：Free, Premium, Ultimate
提供：GitLab.com, GitLab 自托管, GitLab Dedicated

评审应用是为每个分支或合并请求自动创建的临时测试环境。你可以在无需设置本地开发环境的情况下预览和验证变更。

基于动态环境构建，评审应用为每个分支或合并请求提供唯一的环境。

这些环境通过以下方式简化开发工作流：

消除本地设置以测试变更的需求。
为所有团队成员提供一致的环境。
使利益相关者能够通过URL预览变更。
促进在生产环境之前更快地获取反馈循环。

如果你有Kubernetes集群，可以使用Auto DevOps自动设置评审应用。

评审应用工作流

评审应用的工作流可能类似于：

%%{init: { "fontFamily": "GitLab Sans" }}%%
flowchart TD
    accTitle: 评审应用工作流
    accDescr: 显示评审应用如何融入GitLab开发工作流的图表。

    subgraph Development["开发"]
        TopicBranch["创建主题分支"]
        Commit["进行代码变更"]
        CreateMR["创建合并请求"]
    end

    subgraph ReviewAppCycle["评审应用周期"]
        direction LR
        Pipeline["CI/CD流水线运行"]
        ReviewApp["评审应用已部署"]
        Testing["评审与测试"]
        Feedback["提供反馈"]
        NewCommits["根据反馈添加新提交"]
    end

    subgraph Deployment["部署"]
        Approval["合并请求获批准"]
        Merge["合并到默认分支"]
        Production["部署到生产环境"]
    end

    TopicBranch --> Commit
    Commit --> CreateMR
    CreateMR --> Pipeline

    Pipeline --> ReviewApp
    ReviewApp --> Testing
    Testing --> Feedback
    Feedback --> NewCommits
    NewCommits --> Pipeline

    Testing --> Approval
    Approval --> Merge
    Merge --> Production

    classDef devNode fill:#e1e1e1,stroke:#666,stroke-width:1px
    classDef reviewNode fill:#fff0dd,stroke:#f90,stroke-width:1px
    classDef finalNode fill:#d5f5ff,stroke:#0095cd,stroke-width:1px

    class TopicBranch,Commit,CreateMR devNode
    class Pipeline,ReviewApp,Testing,Feedback,NewCommits reviewNode
    class Approval,Merge,Production finalNode

配置评审应用

当你想为每个分支或合并请求提供应用的预览环境时，配置评审应用。

先决条件：

你必须拥有项目的至少Developer角色。
项目中必须有可用的CI/CD流水线。
你必须设置基础设施来托管和部署评审应用。

要在项目中配置评审应用：

在左侧边栏中，选择搜索或前往并找到你的项目。
选择构建 > 流水线编辑器。

在你的.gitlab-ci.yml文件中，添加一个创建动态环境的任务。你可以使用预定义CI/CD变量来区分每个环境。例如，使用CI_COMMIT_REF_SLUG预定义变量：

review_app:
  stage: deploy
  script:
    - echo "部署到评审应用环境"
    # 在此处添加你的部署命令
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.example.com
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH

可选。向任务中添加when: manual，以便仅手动部署评审应用。
可选。添加一个任务来停止评审应用，当它不再需要时。
输入提交消息并选择提交更改。

使用评审应用模板

GitLab 提供了一个内置模板，默认配置用于合并请求流水线。

若要使用和自定义此模板：

在左侧边栏中，选择「搜索或前往」并找到您的项目。
选择「运维 > 环境」。
选择「启用评审应用」。

从出现的「启用评审应用」对话框中，复制以下 YAML 模板：

deploy_review:
  stage: deploy
  script:
    - echo "在此处添加部署代码到您的基础设施的脚本"
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

选择「构建 > 流水线编辑器」。
将模板粘贴到您的 .gitlab-ci.yml 文件中。

根据您的部署需求自定义模板：

修改部署脚本和环境 URL 以适配您的基础设施。
如果希望即使没有合并请求也能触发评审应用，请调整规则部分。

例如，部署到 Heroku 时：

deploy_review:
  stage: deploy
  image: ruby:latest
  script:
    - apt-get update -qy
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$HEROKU_APP_NAME.herokuapp.com
    on_stop: stop_review_app
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

此配置会在合并请求的流水线运行时自动部署到 Heroku。它使用 Ruby 的 dpl 部署工具处理流程，并创建可通过指定 URL 访问的动态评审环境。

输入提交信息并选择「提交更改」。

停止评审应用

您可以配置评审应用以手动或自动方式停止，从而节省资源。

有关停止评审应用环境的更多信息，请参阅停止环境。

合并时自动停止评审应用

若要配置评审应用在关联的合并请求被合并或分支被删除时自动停止：

向部署作业添加on_stop 关键字。
创建带有environment:action: stop 的停止作业。
可选。向停止作业添加when: manual，以便随时手动停止评审应用。

例如：

# 在您的 .gitlab-ci.yml 文件中
deploy_review:
  # 其他配置...
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    url: https://${CI_ENVIRONMENT_SLUG}.example.com
    on_stop: stop_review_app  # 引用 stop_review_app 作业

stop_review_app:
  stage: deploy
  script:
    - echo "停止评审应用"
    # 在此处添加清理命令
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    action: stop
  when: manual  # 使该作业可手动触发
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

基于时间的自动停止

若要配置评审应用在一段时间后自动停止，向部署作业添加auto_stop_in 关键字：

# 在您的 .gitlab-ci.yml 文件中
review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 week  # 一周无活动后停止
  rules:
    - if: $CI_MERGE_REQUEST_ID

查看评审应用

若要部署并访问评审应用：

进入您的合并请求。
可选。如果评审应用作业是手动的，选择「运行」（）以触发部署。
当流水线完成后，选择「查看应用」以在浏览器中打开评审应用。

示例实现

这些项目展示了不同的审查应用实现方式：

项目	配置文件
NGINX	.gitlab-ci.yml
OpenShift	.gitlab-ci.yml
HashiCorp Nomad	.gitlab-ci.yml
GitLab Documentation	build.gitlab-ci.yml
`https://about.gitlab.com/`	.gitlab-ci.yml
GitLab Insights	.gitlab-ci.yml

其他审查应用示例：

路由映射

路由映射让你可以直接从源文件导航到审查应用环境中的对应公共页面。此功能让在合并请求中预览特定变更更加容易。

配置后，路由映射会添加上下文链接，让你查看与映射模式匹配的文件的审查应用版本。这些链接出现在：

合并请求小部件中。
提交和文件视图中。

配置路由映射

要设置路由映射：

在仓库中创建一个文件 .gitlab/route-map.yml。
定义源路径（仓库内）与公共路径（审查应用基础设施或网站上的）之间的映射关系。

路由映射是一个 YAML 数组，其中每个条目将 source 路径映射到 public 路径。

路由映射中的每个映射遵循以下格式：

- source: 'path/to/source/file'  # 仓库中的源文件
  public: 'path/to/public/page'  # 网站上的公共页面

你可以使用两种类型的映射：

精确匹配：单引号内的字符串字面量
模式匹配：正斜杠内的正则表达式

对于使用正则表达式的模式匹配：

正则必须匹配整个源路径（^ 和 $ 锚点隐含）。
你可以使用捕获组 ()，这些捕获组可以在 public 路径中被引用。
使用 \N 表达式按出现顺序引用捕获组（\1、\2 等）。
将斜杠（/）转义为 \/，句点（.）转义为 \.。

GitLab 会按照定义的顺序评估映射。第一个匹配的 source 表达式决定了 public 路径。

示例路由映射

以下示例展示了用于 Middleman 的路由映射，这是一个用于 GitLab 网站的静态站点生成器：

# 团队数据
- source: 'data/team.yml'  # data/team.yml
  public: 'team/'  # team/

# 博客文章
- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/  # source/posts/2017-01-30-around-the-world-in-6-releases.html.md.erb
  public: '////'  # 2017/01/30/around-the-world-in-6-releases/

# HTML 文件
- source: /source\/(.+?\.html).*/  # source/index.html.haml
  public: ''  # index.html

# 其他文件
- source: /source\/(.*)/  # source/images/blogimages/around-the-world-in-6-releases-cover.png
  public: ''  # images/blogimages/around-the-world-in-6-releases-cover.png

在此示例中：

映射按顺序进行评估。
第三个映射确保 source/index.html.haml 匹配 /source\/(.+?\.html).*/ 而不是通用的 /source\/(.*)/。这会产生 index.html 而非 index.html.haml 的公共路径。

查看映射页面

使用路由映射直接从源文件导航到评审应用中的对应页面。

前提条件：

您必须在 .gitlab/route-map.yml 中配置了路由映射。
您的分支或合并请求必须已部署评审应用。

从合并请求小部件中查看映射页面：

在合并请求小部件中，选择「查看应用」。下拉列表显示最多5个映射页面（如果更多可用则提供筛选）。

从文件中查看映射页面：

通过以下方法之一前往与您的路由映射匹配的文件：
- 来自合并请求：在「更改」标签页中，选择「查看文件 @ [提交]」。
- 来自提交页面：选择文件名。
- 来自比较：在比较修订时，选择文件名。
在文件的页面中，选择右上角的「在 [环境名称] 上查看」( )。

从提交中查看映射页面：

前往有评审应用部署的提交：
- 对于分支流水线：选择「代码 > 提交」并选择带有流水线徽章的提交。
- 对于合并请求流水线：在您的合并请求中，选择「提交」标签页并选择一个提交。
- 对于合并结果流水线：在您的合并请求中，选择「流水线」标签页并选择流水线提交。
选择与您的路由映射匹配的文件名旁边的评审应用图标 ( )。该图标会在您的评审应用中打开对应的页面。

合并结果流水线会创建一个内部提交，将您的分支与目标分支合并。要访问这些流水线的评审应用链接，请使用「流水线」标签页中的提交，而不是「提交」标签页中的提交。