# Auto DevOps
> 原文：[https://docs.gitlab.com/ee/topics/autodevops/](https://docs.gitlab.com/ee/topics/autodevops/)
* [Overview](#overview)
* [Enabled by default](#enabled-by-default)
* [Quick start](#quick-start)
* [Comparison to application platforms and PaaS](#comparison-to-application-platforms-and-paas)
* [Features](#features)
* [Auto DevOps base domain](#auto-devops-base-domain)
* [Enabling/Disabling Auto DevOps](#enablingdisabling-auto-devops)
* [At the project level](#at-the-project-level)
* [At the group level](#at-the-group-level)
* [At the instance level (Administrators only)](#at-the-instance-level-administrators-only)
* [Deployment strategy](#deployment-strategy)
* [Using multiple Kubernetes clusters](#using-multiple-kubernetes-clusters-premium)
* [Limitations](#limitations)
* [Private registry support](#private-registry-support)
* [Installing Helm behind a proxy](#installing-helm-behind-a-proxy)
* [Troubleshooting](#troubleshooting)
* [Unable to select a buildpack](#unable-to-select-a-buildpack)
* [Pipeline that extends Auto DevOps with only / except fails](#pipeline-that-extends-auto-devops-with-only--except-fails)
* [Failure to create a Kubernetes namespace](#failure-to-create-a-kubernetes-namespace)
* [Detected an existing PostgreSQL database](#detected-an-existing-postgresql-database)
* [Development guides](#development-guides)
# Auto DevOps[](#auto-devops "Permalink")
版本历史
* 在 GitLab 10.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37115) .
* 通常在 GitLab 11.0 上可用.
Auto DevOps provides pre-defined CI/CD configuration allowing you to automatically detect, build, test, deploy, and monitor your applications. Leveraging CI/CD best practices and tools, Auto DevOps aims to simplify the setup and execution of a mature and modern software development lifecycle.
## Overview[](#overview "Permalink")
您可以花费大量精力来设置构建，部署和监视项目所需的工作流和流程. 当您的公司要维护数百个（甚至数千个）项目时，情况会变得更糟. 随着新项目的不断启动，整个软件开发过程变得难以管理.
Auto DevOps 通过自动检测以最小的配置测试，构建，打包，部署和监视每个项目所需的所有依赖关系和语言技术，为您提供了无缝的软件开发过程. 自动化可确保项目之间的一致性，流程的无缝管理以及更快地创建新项目：推送代码，而 GitLab 则完成其余工作，从而提高了生产率和效率.
有关 Auto DevOps 的介绍， [请在 GitLab 11.0 中](https://youtu.be/0Tc0YYBxqi4)观看[AutoDevOps](https://youtu.be/0Tc0YYBxqi4) .
有关要求，请参阅[Auto DevOps 要求以](requirements.html)获取更多信息.
## Enabled by default[](#enabled-by-default "Permalink")
在 GitLab 11.3 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) .
默认情况下，所有项目都会启用 Auto DevOps，并尝试在每个项目的所有管道中运行. 实例管理员可以在[Auto DevOps 设置中](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only)启用或禁用此默认[设置](../../user/admin_area/settings/continuous_integration.html#auto-devops-core-only) . 如果尚未为项目显式启用，Auto DevOps 会在各个项目的第一个管道故障时自动将其禁用.
从[GitLab 12.7 开始](https://gitlab.com/gitlab-org/gitlab/-/issues/26655) ，仅当存在[`Dockerfile`或匹配的 buildpack](stages.html#auto-build)时，Auto DevOps 才会在管道上自动运行.
如果项目中存在[CI / CD 配置文件](../../ci/yaml/README.html) ，则无论是否启用了 Auto DevOps，它都将继续使用.
## Quick start[](#quick-start "Permalink")
如果您使用的是 GitLab.com，请参阅[快速入门指南](quick_start_guide.html) ，以使用 GitLab.com 和 Google Kubernetes Engine（GKE）上的 Kubernetes 集群设置 Auto DevOps.
如果使用 GitLab 的自我管理实例，则必须先配置[Google OAuth2 OmniAuth Provider，](../../integration/google.html)然后才能在 GKE 上配置集群. 配置提供程序后，您可以按照[快速入门指南中](quick_start_guide.html)的步骤进行入门.
In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.html#auto-devops-requirements-for-amazon-ecs).
## Comparison to application platforms and PaaS[](#comparison-to-application-platforms-and-paas "Permalink")
Auto DevOps provides features often included in an application platform or a Platform as a Service (PaaS). It takes inspiration from the innovative work done by [Heroku](https://www.heroku.com/) and goes beyond it in multiple ways:
* Auto DevOps 可与任何 Kubernetes 集群一起使用; 您不仅限于在 GitLab 的基础架构上运行. （请注意，许多功能在没有 Kubernetes 的情况下也可以使用）.
* 没有额外的费用（基础设施费用没有加价），您可以在任何公共云（例如[Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) ）上使用托管的 Kubernetes 群集或容器即服务.
* Auto DevOps 具有更多功能，包括安全测试，性能测试和代码质量测试.
* Auto DevOps 提供增量的毕业路径. 如果需要高级自定义，则可以开始修改模板，而无需在完全不同的平台上重新开始. 查看[定制](customize.html)文档以获取更多信息.
## Features[](#features "Permalink")
Auto DevOps 由一组[阶段组成](stages.html) ，以简单，自动的方式为您的项目带来了这些最佳实践：
1. [Auto Build](stages.html#auto-build)
2. [Auto Test](stages.html#auto-test)
3. [Auto Code Quality](stages.html#auto-code-quality-starter)
4. [Auto SAST (Static Application Security Testing)](stages.html#auto-sast-ultimate)
5. [Auto Secret Detection](stages.html#auto-secret-detection-ultimate)
6. [Auto Dependency Scanning](stages.html#auto-dependency-scanning-ultimate)
7. [Auto License Compliance](stages.html#auto-license-compliance-ultimate)
8. [Auto Container Scanning](stages.html#auto-container-scanning-ultimate)
9. [Auto Review Apps](stages.html#auto-review-apps)
10. [Auto DAST (Dynamic Application Security Testing)](stages.html#auto-dast-ultimate)
11. [Auto Deploy](stages.html#auto-deploy)
12. [Auto Browser Performance Testing](stages.html#auto-browser-performance-testing-premium)
13. [Auto Monitoring](stages.html#auto-monitoring)
由于 Auto DevOps 依赖于许多不同的组件，因此您应该具有以下基本知识：
* [Kubernetes](https://kubernetes.io/docs/home/)
* [Helm](https://helm.sh/docs/)
* [Docker](https://s0docs0docker0com.icopy.site)
* [GitLab Runner](https://docs.gitlab.com/runner/)
* [Prometheus](https://s0prometheus0io.icopy.site/docs/introduction/overview/)
Auto DevOps 为所有阶段提供了出色的默认设置. 但是，您可以[根据](customize.html)需要[自定义](customize.html)几乎所有内容.
有关创建 Auto DevOps 的概述，请阅读[本博客文章中的](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/)更多[信息](https://about.gitlab.com/blog/2017/06/29/whats-next-for-gitlab-ci/) .
**注意** Kubernetes 集群可以[在没有](../../user/project/clusters/index.html) Auto DevOps 的[情况下使用](../../user/project/clusters/index.html) .
## Auto DevOps base domain[](#auto-devops-base-domain "Permalink")
必须使用 Auto DevOps 基本域才能使用[Auto Review Apps](stages.html#auto-review-apps) ， [Auto Deploy](stages.html#auto-deploy)和[Auto Monitoring](stages.html#auto-monitoring) . 您可以在以下任意位置定义基本域：
* 在集群的设置下（对于实例， [项目](../../user/project/clusters/index.html#base-domain)还是[组）](../../user/group/clusters/index.html#base-domain)
* 或在项目级别作为变量： `KUBE_INGRESS_BASE_DOMAIN`
* 或在组级别作为变量： `KUBE_INGRESS_BASE_DOMAIN`
* 或作为实例范围的后备 **持续集成和交付**部分下的**管理区域>设置**
基本域变量`KUBE_INGRESS_BASE_DOMAIN`与其他环境[变量](../../ci/variables/README.html#priority-of-environment-variables)遵循相同的优先级顺序. 如果未设置 CI / CD 变量，并且群集设置为空，则在设置实例范围的**Auto DevOps 域**设置时将使用该设置.
**提示：**如果您将[GitLab 托管应用程序用于 Ingress](../../user/clusters/applications.html#ingress) ，则应自动为您配置 URL 端点. 您所要做的就是将其值用于`KUBE_INGRESS_BASE_DOMAIN`变量.**注：** `AUTO_DEVOPS_DOMAIN`被[弃用 GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52363) ，取而代之的`KUBE_INGRESS_BASE_DOMAIN` ，并在除去[GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/56959) .
Auto DevOps 需要与基础域匹配的通配符 DNS A 记录. 对于`example.com`的基本域，您需要一个 DNS 条目，例如：
```
*.example.com 3600 A 1.2.3.4
```
在这种情况下，已部署的应用程序是从`example.com` ，而`1.2.3.4`是负载均衡器的 IP 地址. 通常为 NGINX（ [请参阅要求](#requirements) ）. 设置 DNS 记录不在本文档的讨论范围内. 请与您的 DNS 提供商联系以获取信息.
另外，您可以使用免费的公共服务，例如[nip.io](https://nip.io) ，无需任何配置即可提供自动通配符 DNS. 对于[nip.io](https://nip.io) ，将 Auto DevOps 基本域设置为`1.2.3.4.nip.io`
完成设置后，所有请求都将到达负载均衡器，该负载均衡器会将请求路由到运行您的应用程序的 Kubernetes Pod.
## Enabling/Disabling Auto DevOps[](#enablingdisabling-auto-devops "Permalink")
首次使用 Auto DevOps 时，请查看[要求，](#requirements)以确保可以充分利用 Auto DevOps 的所有必需组件. 初学者应遵循[快速入门指南](quick_start_guide.html) .
GitLab.com 用户只能在项目级别启用或禁用 Auto DevOps. 自我管理的用户可以在项目，组或实例级别启用或禁用 Auto DevOps.
### At the project level[](#at-the-project-level "Permalink")
如果启用，请检查您的项目是否没有`.gitlab-ci.yml` ，或者如果存在，请将其删除.
1. 转到项目的 **设置> CI / CD>自动 DevOps** .
2. 选中**默认为 Auto DevOps 管道**复选框以启用它.
3. （可选，但建议使用）启用后，您可以在 Auto DevOps 用于[部署应用程序](stages.html#auto-deploy)的[基本域中](#auto-devops-base-domain)添加，并选择[部署策略](#deployment-strategy) .
4. 单击**保存更改**以使更改生效.
启用该功能后，将在默认分支上触发 Auto DevOps 管道.
### At the group level[](#at-the-group-level "Permalink")
在 GitLab 11.10 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/52447) .
仅管理员和组所有者可以在组级别启用或禁用自动 DevOps.
在组级别启用或禁用 Auto DevOps 时，除非在子组或项目上专门启用或禁用了 Auto DevOps，否则组配置将隐式用于该组内的子组和项目.
要在组级别启用或禁用自动 DevOps：
1. 前往您小组的 **设置> CI / CD>自动 DevOps**页面.
2. 选中**默认为 Auto DevOps 管道**复选框以启用它.
3. 单击**保存更改**以使更改生效.
### At the instance level (Administrators only)[](#at-the-instance-level-administrators-only "Permalink")
即使在实例级别被禁用，组所有者和项目维护者仍可以分别在组和项目级别启用 Auto DevOps.
1. 去 **管理区域>设置>持续集成和部署** .
2. **为所有项目**选择" **默认为自动 DevOps 管道"**以启用它.
3. （可选）您可以设置 Auto DevOps [基本域](#auto-devops-base-domain) ，以供 Auto Deploy 和 Auto Review Apps 使用.
4. 单击**保存更改**以使更改生效.
### Deployment strategy[](#deployment-strategy "Permalink")
在 GitLab 11.0 中[引入](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) .
您可以转到项目的目录，更改 Auto DevOps 使用的部署策略. **设置> CI / CD>自动 DevOps** . 提供以下选项：
* **持续部署到生产中** ：启用将`master`分支直接部署到生产中的[自动部署](stages.html#auto-deploy) .
* **使用定时增量部署连续部署到生产中** ：将[`INCREMENTAL_ROLLOUT_MODE`](customize.html#timed-incremental-rollout-to-production-premium)变量设置为`timed` . 生产部署在每次部署增量之间有 5 分钟的延迟执行.
* **自动部署到登台，手动部署到生产** ：将[`STAGING_ENABLED`](customize.html#deploy-policy-for-staging-and-production-environments)和[`INCREMENTAL_ROLLOUT_MODE`](customize.html#incremental-rollout-to-production-premium)变量设置为`1`并`manual` . 这表示：
* `master`分支直接部署到登台.
* 提供了手动操作以逐步推广到生产中.
**提示：**使用[蓝绿色部署](../../ci/environments/incremental_rollouts.html#blue-green-deployment)技术可最大程度地减少停机时间和风险.
## Using multiple Kubernetes clusters[](#using-multiple-kubernetes-clusters-premium "Permalink")
使用 Auto DevOps 时，由于[它们之间存在](../../user/project/clusters/index.html#multiple-kubernetes-clusters-premium) 1：1 连接，因此可以将不同的环境部署到不同的 Kubernetes 集群.
Auto DevOps 使用的" [部署作业"模板](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Jobs/Deploy.gitlab-ci.yml)当前定义了 3 个环境名称：
* `review/` （从`review/`开始的所有环境`review/` ）
* `staging`
* `production`
这些环境使用[Auto Deploy](stages.html#auto-deploy)与作业绑定，因此，除了环境范围外，它们必须具有不同的部署域. 您必须[根据环境](../../ci/variables/README.html#limit-the-environment-scopes-of-environment-variables)为上述每个项定义一个单独的`KUBE_INGRESS_BASE_DOMAIN`变量.
下表是如何配置三个不同群集的示例：
| 集群名称 | 集群环境范围 | `KUBE_INGRESS_BASE_DOMAIN`变量值 | 可变环境范围 | Notes |
| --- | --- | --- | --- | --- |
| review | `review/*` | `review.example.com` | `review/*` | 运行所有[Review Apps](../../ci/review_apps/index.html)的评论集群. `*`是一个通配符，每个环境名称都以`review/`开头使用. |
| staging | `staging` | `staging.example.com` | `staging` | （可选）运行临时环境的部署的临时集群. 您必须先[启用它](customize.html#deploy-policy-for-staging-and-production-environments) . |
| production | `production` | `example.com` | `production` | 运行生产环境部署的生产集群. 您可以使用[增量卷展栏](customize.html#incremental-rollout-to-production-premium) . |
为每个环境添加不同的集群：
1. 导航到您项目的 **运营> Kubernetes** .
2. 如上表所述，使用各自的环境范围创建 Kubernetes 集群.
3. 创建集群后，导航至每个集群并安装 Helm Tiller 和 Ingress. 等待分配入口 IP 地址.
4. 确保已使用指定的 Auto DevOps 域[配置 DNS](#auto-devops-base-domain) .
5. 导航到每个集群的页面，方法是 **操作> Kubernetes** ，然后根据其入口 IP 地址添加域.
完成配置后，您可以通过创建合并请求并验证您的应用程序是否已作为具有 Review `review/*`环境范围的 Kubernetes 集群中的 Review App 部署来测试设置. 同样，您可以检查其他环境.
## Limitations[](#limitations "Permalink")
以下限制适用.
### Private registry support[](#private-registry-support "Permalink")
没有记录的将私有容器注册表与 Auto DevOps 结合使用的方式. 我们强烈建议将 GitLab 容器注册表与 Auto DevOps 结合使用，以简化配置并防止任何不可预见的问题.
### Installing Helm behind a proxy[](#installing-helm-behind-a-proxy "Permalink")
当在代理后面时，GitLab 不支持将[Helm 作为 GitLab 管理的应用程序](../../user/clusters/applications.html#helm)安装. 想要这样做的用户必须在运行时将其代理设置注入到安装 Pod 中，例如使用[`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/) ：
```
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: gitlab-managed-apps-default-proxy
namespace: gitlab-managed-apps
spec:
env:
- name: http_proxy
value: "PUT_YOUR_HTTP_PROXY_HERE"
- name: https_proxy
value: "PUT_YOUR_HTTPS_PROXY_HERE"
```
## Troubleshooting[](#troubleshooting "Permalink")
### Unable to select a buildpack[](#unable-to-select-a-buildpack "Permalink")
自动构建和自动测试可能无法检测到您的语言或框架，并出现以下错误：
```
Step 5/11 : RUN /bin/herokuish buildpack build
---> Running in eb468cd46085
-----> Unable to select a buildpack
The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1
```
以下是可能的原因：
* 您的应用程序可能缺少 buildpack 寻找的关键文件. Ruby 应用程序需要正确检测`Gemfile` ，即使编写不带`Gemfile`的 Ruby 应用程序也是`Gemfile` .
* 您的应用程序可能不存在 buildpack. 尝试指定[自定义 buildpack](customize.html#custom-buildpacks) .
### Pipeline that extends Auto DevOps with only / except fails[](#pipeline-that-extends-auto-devops-with-only--except-fails "Permalink")
如果您的管道失败并显示以下消息：
```
Found errors in your .gitlab-ci.yml:
jobs:test config key may not be used with `rules`: only
```
当包含作业的规则配置已被`only`或`except`语法覆盖时，将出现此错误. 要解决此问题，您必须：
* 将您的`only/except`语法转换为规则.
* （临时）将模板固定到[基于 GitLab 12.10 的模板](https://gitlab.com/gitlab-org/auto-devops-v12-10) .
### Failure to create a Kubernetes namespace[](#failure-to-create-a-kubernetes-namespace "Permalink")
如果 GitLab 无法为您的项目创建 Kubernetes 命名空间和服务帐户，则 Auto Deploy 将失败. 有关调试此问题的帮助，请参阅[对失败的部署作业进行故障排除](../../user/project/clusters/index.html#troubleshooting) .
### Detected an existing PostgreSQL database[](#detected-an-existing-postgresql-database "Permalink")
升级到 GitLab 13.0 后，使用 Auto DevOps 部署时可能会遇到以下消息：
> 检测到已安装在不赞成使用的通道 1 上的现有 PostgreSQL 数据库，但当前通道设置为 2.在 GitLab 13.0 中，默认通道更改为 2\. […]
默认情况下，Auto DevOps 会在应用程序旁边安装集群内 PostgreSQL 数据库. 在 GitLab 13.0 中更改了默认安装方法，并且升级现有数据库需要用户参与. 两种安装方法是：
* **通道 1（不建议使用）：**作为关联的 Helm 图表的依赖项拉入数据库. 只支持 Kubernetes 版本 1.15 之前的版本.
* **通道 2（当前）：**将数据库安装为独立的 Helm 图表. 将集群内数据库功能与 Kubernetes 1.16 及更高版本一起使用时是必需的.
如果收到此错误，则可以执行以下操作之一：
* 通过将`AUTO_DEVOPS_POSTGRES_CHANNEL`设置为`1`并重新部署，可以*放心地*忽略该警告并继续使用通道 1 PostgreSQL 数据库.
* 通过将`AUTO_DEVOPS_POSTGRES_DELETE_V1`设置为非空值并重新部署，可以删除通道 1 PostgreSQL 数据库并安装新的通道 2 数据库.
**危险：**删除通道 1 PostgreSQL 数据库将永久删除现有的通道 1 数据库及其所有数据. 有关备份和升级数据库的更多信息，请参见[升级 PostgreSQL](upgrading_postgresql.html) .
* 如果不使用集群内数据库，则可以将`POSTGRES_ENABLED`设置为`false`并重新部署. 此选项与*没有图表内 PostgreSQL 依赖项*的*自定义图表的*用户特别相关. 数据库自动检测基于您的发行版的`postgresql.enabled` Helm 值. 该值是基于`POSTGRES_ENABLED` CI 变量设置的，并且由 Helm 保留，无论您的图表是否使用该变量.
**危险：**将`POSTGRES_ENABLED`设置为`false`永久删除您环境中的任何现有通道 1 数据库.
## Development guides[](#development-guides "Permalink")
[Development guide for Auto DevOps](../../development/auto_devops.html)
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license