Commit 821b8058 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

Merge branch 'docs-autodevops-notes-review' into 'master'

Remove unnecessary notes from AutoDevOps documentation

See merge request gitlab-org/gitlab-ce!27433
parents a7f50426 eae8e422
...@@ -8,7 +8,14 @@ to simplify the setup and execution of a mature & modern software development li ...@@ -8,7 +8,14 @@ to simplify the setup and execution of a mature & modern software development li
## Overview ## Overview
NOTE: **Enabled by default:** With Auto DevOps, the software development process becomes easier to set up
as every project can have a complete workflow from verification to monitoring
with minimal configuration. Just push your code and GitLab takes
care of everything else. This makes it easier to start new projects and brings
consistency to how applications are set up throughout a company.
## Enabled by default
Starting with GitLab 11.3, the Auto DevOps pipeline is enabled by default for all Starting with GitLab 11.3, the Auto DevOps pipeline is enabled by default for all
projects. If it has not been explicitly enabled for the project, Auto DevOps will be automatically projects. If it has not been explicitly enabled for the project, Auto DevOps will be automatically
disabled on the first pipeline failure. Your project will continue to use an alternative disabled on the first pipeline failure. Your project will continue to use an alternative
...@@ -16,12 +23,6 @@ disabled on the first pipeline failure. Your project will continue to use an alt ...@@ -16,12 +23,6 @@ disabled on the first pipeline failure. Your project will continue to use an alt
administrator can [change this setting](../../user/admin_area/settings/continuous_integration.md#auto-devops-core-only) administrator can [change this setting](../../user/admin_area/settings/continuous_integration.md#auto-devops-core-only)
in the admin area. in the admin area.
With Auto DevOps, the software development process becomes easier to set up
as every project can have a complete workflow from verification to monitoring
with minimal configuration. Just push your code and GitLab takes
care of everything else. This makes it easier to start new projects and brings
consistency to how applications are set up throughout a company.
## Quick start ## Quick start
If you are using GitLab.com, see the [quick start guide](quick_start_guide.md) If you are using GitLab.com, see the [quick start guide](quick_start_guide.md)
...@@ -62,7 +63,7 @@ project in a simple and automatic way: ...@@ -62,7 +63,7 @@ project in a simple and automatic way:
1. [Auto SAST (Static Application Security Testing)](#auto-sast-ultimate) **[ULTIMATE]** 1. [Auto SAST (Static Application Security Testing)](#auto-sast-ultimate) **[ULTIMATE]**
1. [Auto Dependency Scanning](#auto-dependency-scanning-ultimate) **[ULTIMATE]** 1. [Auto Dependency Scanning](#auto-dependency-scanning-ultimate) **[ULTIMATE]**
1. [Auto License Management](#auto-license-management-ultimate) **[ULTIMATE]** 1. [Auto License Management](#auto-license-management-ultimate) **[ULTIMATE]**
1. [Auto Container Scanning](#auto-container-scanning) 1. [Auto Container Scanning](#auto-container-scanning-ultimate) **[ULTIMATE]**
1. [Auto Review Apps](#auto-review-apps) 1. [Auto Review Apps](#auto-review-apps)
1. [Auto DAST (Dynamic Application Security Testing)](#auto-dast-ultimate) **[ULTIMATE]** 1. [Auto DAST (Dynamic Application Security Testing)](#auto-dast-ultimate) **[ULTIMATE]**
1. [Auto Deploy](#auto-deploy) 1. [Auto Deploy](#auto-deploy)
...@@ -120,7 +121,6 @@ To make full use of Auto DevOps, you will need: ...@@ -120,7 +121,6 @@ To make full use of Auto DevOps, you will need:
[default service template](../../user/project/integrations/services_templates.md) [default service template](../../user/project/integrations/services_templates.md)
for the entire GitLab installation. for the entire GitLab installation.
NOTE: **Note:**
If you do not have Kubernetes or Prometheus installed, then Auto Review Apps, If you do not have Kubernetes or Prometheus installed, then Auto Review Apps,
Auto Deploy, and Auto Monitoring will be silently skipped. Auto Deploy, and Auto Monitoring will be silently skipped.
...@@ -135,10 +135,13 @@ in any of the following places: ...@@ -135,10 +135,13 @@ in any of the following places:
- or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN` - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
- or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`. - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`.
NOTE: **Note** The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
The Auto DevOps base domain variable (`KUBE_INGRESS_BASE_DOMAIN`) follows the same order of precedence
as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables). as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
NOTE: **Note**
`AUTO_DEVOPS_DOMAIN` environment variable is deprecated and
[is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-ce/issues/56959).
A wildcard DNS A record matching the base domain(s) is required, for example, A wildcard DNS A record matching the base domain(s) is required, for example,
given a base domain of `example.com`, you'd need a DNS entry like: given a base domain of `example.com`, you'd need a DNS entry like:
...@@ -222,19 +225,20 @@ can enable/disable Auto DevOps at either the project-level or instance-level. ...@@ -222,19 +225,20 @@ can enable/disable Auto DevOps at either the project-level or instance-level.
### Enabling/disabling Auto DevOps at the instance-level (Administrators only) ### Enabling/disabling Auto DevOps at the instance-level (Administrators only)
Even when disabled at the instance level, group owners and project maintainers can still enable
Auto DevOps at the group and project level, respectively.
1. Go to **Admin area > Settings > Continuous Integration and Deployment**. 1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**. 1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**.
1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps. 1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps.
1. Click **Save changes** for the changes to take effect. 1. Click **Save changes** for the changes to take effect.
NOTE: **Note:**
Even when disabled at the instance level, group owners and project maintainers are still able to enable
Auto DevOps at group-level and project-level, respectively.
### Enabling/disabling Auto DevOps at the group-level ### Enabling/disabling Auto DevOps at the group-level
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/52447) in GitLab 11.10. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/52447) in GitLab 11.10.
Only administrators and group owners can enable or disable Auto DevOps at the group level.
To enable or disable Auto DevOps at the group-level: To enable or disable Auto DevOps at the group-level:
1. Go to group's **Settings > CI/CD > Auto DevOps** page. 1. Go to group's **Settings > CI/CD > Auto DevOps** page.
...@@ -245,9 +249,6 @@ When enabling or disabling Auto DevOps at group-level, group configuration will ...@@ -245,9 +249,6 @@ When enabling or disabling Auto DevOps at group-level, group configuration will
the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on
the subgroup or project. the subgroup or project.
NOTE: **Note**
Only administrators and group owners are allowed to enable or disable Auto DevOps at group-level.
### Enabling/disabling Auto DevOps at the project-level ### Enabling/disabling Auto DevOps at the project-level
If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it. If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it.
...@@ -261,16 +262,13 @@ If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one ...@@ -261,16 +262,13 @@ If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one
When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch. When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch.
NOTE: **Note:** ### Feature flag to enable for a percentage of projects
For GitLab versions 10.0 - 10.2, when enabling Auto DevOps, a pipeline needs to be
manually triggered either by pushing a new commit to the repository or by visiting
`https://example.gitlab.com/<username>/<project>/pipelines/new` and creating
a new pipeline for your default branch, generally `master`.
NOTE: **Note:** There is also a feature flag to enable Auto DevOps by default to your chosen percentage of projects.
There is also a feature flag to enable Auto DevOps to a percentage of projects
which can be enabled from the console with This can be enabled from the console with the following, which uses the example of 10%:
`Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10)`.
`Feature.get(:force_autodevops_on_by_default).enable_percentage_of_actors(10)`
### Deployment strategy ### Deployment strategy
...@@ -350,7 +348,6 @@ frameworks are detected automatically, but if your language is not detected, ...@@ -350,7 +348,6 @@ frameworks are detected automatically, but if your language is not detected,
you may succeed with a [custom buildpack](#custom-buildpacks). Check the you may succeed with a [custom buildpack](#custom-buildpacks). Check the
[currently supported languages](#currently-supported-languages). [currently supported languages](#currently-supported-languages).
NOTE: **Note:**
Auto Test uses tests you already have in your application. If there are no Auto Test uses tests you already have in your application. If there are no
tests, it's up to you to add them. tests, it's up to you to add them.
...@@ -371,73 +368,66 @@ Any differences between the source and target branches are also ...@@ -371,73 +368,66 @@ Any differences between the source and target branches are also
Static Application Security Testing (SAST) uses the Static Application Security Testing (SAST) uses the
[SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static [SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
analysis on the current code and checks for potential security issues. Once the analysis on the current code and checks for potential security issues. The
report is created, it's uploaded as an artifact which you can later download and the Auto SAST stage will be skipped on licenses other than Ultimate and requires GitLab Runner 11.5 or above.
Once the report is created, it's uploaded as an artifact which you can later download and
check out. check out.
Any security warnings are also shown in the merge request widget. Read more how Any security warnings are also shown in the merge request widget. Read more how
[SAST works](../../user/application_security/sast/index.md). [SAST works](../../user/application_security/sast/index.md).
NOTE: **Note:**
The Auto SAST stage will be skipped on licenses other than Ultimate.
NOTE: **Note:**
The Auto SAST job requires GitLab Runner 11.5 or above.
### Auto Dependency Scanning **[ULTIMATE]** ### Auto Dependency Scanning **[ULTIMATE]**
> Introduced in [GitLab Ultimate][ee] 10.7. > Introduced in [GitLab Ultimate][ee] 10.7.
Dependency Scanning uses the Dependency Scanning uses the
[Dependency Scanning Docker image](https://gitlab.com/gitlab-org/security-products/dependency-scanning) [Dependency Scanning Docker image](https://gitlab.com/gitlab-org/security-products/dependency-scanning)
to run analysis on the project dependencies and checks for potential security issues. Once the to run analysis on the project dependencies and checks for potential security issues.
The Auto Dependency Scanning stage will be skipped on licenses other than Ultimate
and requires GitLab Runner 11.5 or above.
Once the
report is created, it's uploaded as an artifact which you can later download and report is created, it's uploaded as an artifact which you can later download and
check out. check out.
Any security warnings are also shown in the merge request widget. Read more about Any security warnings are also shown in the merge request widget. Read more about
[Dependency Scanning](../../user/application_security/dependency_scanning/index.md). [Dependency Scanning](../../user/application_security/dependency_scanning/index.md).
NOTE: **Note:**
The Auto Dependency Scanning stage will be skipped on licenses other than Ultimate.
NOTE: **Note:**
The Auto Dependency Scanning job requires GitLab Runner 11.5 or above.
### Auto License Management **[ULTIMATE]** ### Auto License Management **[ULTIMATE]**
> Introduced in [GitLab Ultimate][ee] 11.0. > Introduced in [GitLab Ultimate][ee] 11.0.
License Management uses the License Management uses the
[License Management Docker image](https://gitlab.com/gitlab-org/security-products/license-management) [License Management Docker image](https://gitlab.com/gitlab-org/security-products/license-management)
to search the project dependencies for their license. Once the to search the project dependencies for their license. The Auto License Management stage
will be skipped on licenses other than Ultimate.
Once the
report is created, it's uploaded as an artifact which you can later download and report is created, it's uploaded as an artifact which you can later download and
check out. check out.
Any licenses are also shown in the merge request widget. Read more how Any licenses are also shown in the merge request widget. Read more how
[License Management works](../../user/application_security/license_management/index.md). [License Management works](../../user/application_security/license_management/index.md).
NOTE: **Note:** ### Auto Container Scanning **[ULTIMATE]**
The Auto License Management stage will be skipped on licenses other than Ultimate.
### Auto Container Scanning
> Introduced in GitLab 10.4. > Introduced in GitLab 10.4.
Vulnerability Static Analysis for containers uses Vulnerability Static Analysis for containers uses
[Clair](https://github.com/coreos/clair) to run static analysis on a [Clair](https://github.com/coreos/clair) to run static analysis on a
Docker image and checks for potential security issues. Once the report is Docker image and checks for potential security issues. The Auto Container Scanning stage
will be skipped on licenses other than Ultimate.
Once the report is
created, it's uploaded as an artifact which you can later download and created, it's uploaded as an artifact which you can later download and
check out. check out.
Any security warnings are also shown in the merge request widget. Read more how Any security warnings are also shown in the merge request widget. Read more how
[Container Scanning works](../../user/application_security/container_scanning/index.md). [Container Scanning works](../../user/application_security/container_scanning/index.md).
NOTE: **Note:**
The Auto Container Scanning stage will be skipped on licenses other than Ultimate.
### Auto Review Apps ### Auto Review Apps
NOTE: **Note:**
This is an optional step, since many projects do not have a Kubernetes cluster This is an optional step, since many projects do not have a Kubernetes cluster
available. If the [requirements](#requirements) are not met, the job will available. If the [requirements](#requirements) are not met, the job will
silently be skipped. silently be skipped.
...@@ -482,15 +472,14 @@ in the first place, and thus not realize that it needs to re-apply the old confi ...@@ -482,15 +472,14 @@ in the first place, and thus not realize that it needs to re-apply the old confi
Dynamic Application Security Testing (DAST) uses the Dynamic Application Security Testing (DAST) uses the
popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
to perform an analysis on the current code and checks for potential security to perform an analysis on the current code and checks for potential security
issues. Once the report is created, it's uploaded as an artifact which you can issues. The Auto DAST stage will be skipped on licenses other than Ultimate.
Once the report is created, it's uploaded as an artifact which you can
later download and check out. later download and check out.
Any security warnings are also shown in the merge request widget. Read how Any security warnings are also shown in the merge request widget. Read how
[DAST works](../../user/application_security/dast/index.md). [DAST works](../../user/application_security/dast/index.md).
NOTE: **Note:**
The Auto DAST stage will be skipped on licenses other than Ultimate.
### Auto Browser Performance Testing **[PREMIUM]** ### Auto Browser Performance Testing **[PREMIUM]**
> Introduced in [GitLab Premium][ee] 10.4. > Introduced in [GitLab Premium][ee] 10.4.
...@@ -508,7 +497,6 @@ Any performance differences between the source and target branches are also ...@@ -508,7 +497,6 @@ Any performance differences between the source and target branches are also
### Auto Deploy ### Auto Deploy
NOTE: **Note:**
This is an optional step, since many projects do not have a Kubernetes cluster This is an optional step, since many projects do not have a Kubernetes cluster
available. If the [requirements](#requirements) are not met, the job will available. If the [requirements](#requirements) are not met, the job will
silently be skipped. silently be skipped.
...@@ -547,7 +535,7 @@ in the first place, and thus not realize that it needs to re-apply the old confi ...@@ -547,7 +535,7 @@ in the first place, and thus not realize that it needs to re-apply the old confi
For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token) For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token)
will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token
can be used for permanent access to the registry. can be used for permanent access to the registry. When the GitLab Deploy Token has been manually revoked, it won't be automatically created.
If the GitLab Deploy Token cannot be found, `CI_REGISTRY_PASSWORD` is If the GitLab Deploy Token cannot be found, `CI_REGISTRY_PASSWORD` is
used. Note that `CI_REGISTRY_PASSWORD` is only valid during deployment. used. Note that `CI_REGISTRY_PASSWORD` is only valid during deployment.
...@@ -557,9 +545,6 @@ be pulled again, e.g. after pod eviction, Kubernetes will fail to do so ...@@ -557,9 +545,6 @@ be pulled again, e.g. after pod eviction, Kubernetes will fail to do so
as it will be attempting to fetch the image using as it will be attempting to fetch the image using
`CI_REGISTRY_PASSWORD`. `CI_REGISTRY_PASSWORD`.
NOTE: **Note:**
When the GitLab Deploy Token has been manually revoked, it won't be automatically created.
#### Migrations #### Migrations
> [Introduced][ce-21955] in GitLab 11.4 > [Introduced][ce-21955] in GitLab 11.4
...@@ -588,17 +573,13 @@ For example, in a Rails application in an image built with ...@@ -588,17 +573,13 @@ For example, in a Rails application in an image built with
- `DB_INITIALIZE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:setup` - `DB_INITIALIZE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:setup`
- `DB_MIGRATE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:migrate` - `DB_MIGRATE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:migrate`
NOTE: **Note:**
Unless you have a `Dockerfile` in your repo, your image is built with Unless you have a `Dockerfile` in your repo, your image is built with
Herokuish. You must prefix commands run in these images with `/bin/herokuish Herokuish, and you must prefix commands run in these images with `/bin/herokuish
procfile exec` in order to replicate the the environment your application is procfile exec` to replicate the environment where your application will run.
run in.
### Auto Monitoring ### Auto Monitoring
NOTE: **Note:** See the [requirements](#requirements) for Auto Monitoring to enable this stage.
Check the [requirements](#requirements) for Auto Monitoring to make this stage
work.
Once your application is deployed, Auto Monitoring makes it possible to monitor Once your application is deployed, Auto Monitoring makes it possible to monitor
your application's server and response metrics right out of the box. Auto your application's server and response metrics right out of the box. Auto
...@@ -826,11 +807,6 @@ metadata: ...@@ -826,11 +807,6 @@ metadata:
type: Opaque type: Opaque
``` ```
CAUTION: **Caution:**
Variables with multiline values are not currently supported due to
limitations with the current Auto DevOps scripting environment.
NOTE: **Note:**
Environment variables are generally considered immutable in a Kubernetes Environment variables are generally considered immutable in a Kubernetes
pod. Therefore, if you update an application secret without changing any pod. Therefore, if you update an application secret without changing any
code then manually create a new pipeline, you will find that any running code then manually create a new pipeline, you will find that any running
...@@ -839,6 +815,10 @@ can either push a code update to GitLab to force the Kubernetes ...@@ -839,6 +815,10 @@ can either push a code update to GitLab to force the Kubernetes
Deployment to recreate pods or manually delete running pods to Deployment to recreate pods or manually delete running pods to
cause Kubernetes to create new pods with updated secrets. cause Kubernetes to create new pods with updated secrets.
NOTE: **Note:**
Variables with multiline values are not currently supported due to
limitations with the current Auto DevOps scripting environment.
#### Advanced replica variables setup #### Advanced replica variables setup
Apart from the two replica-related variables for production mentioned above, Apart from the two replica-related variables for production mentioned above,
...@@ -1007,8 +987,7 @@ Everything behaves the same way, except: ...@@ -1007,8 +987,7 @@ Everything behaves the same way, except:
## Currently supported languages ## Currently supported languages
NOTE: **Note:** Note that not all buildpacks support Auto Test yet, as it's a relatively new
Not all buildpacks support Auto Test yet, as it's a relatively new
enhancement. All of Heroku's [officially supported enhancement. All of Heroku's [officially supported
languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages) languages](https://devcenter.heroku.com/articles/heroku-ci#currently-supported-languages)
support it, and some third-party buildpacks as well e.g., Go, Node, Java, PHP, support it, and some third-party buildpacks as well e.g., Go, Node, Java, PHP,
......
...@@ -161,7 +161,7 @@ In the **test** stage, GitLab runs various checks on the application: ...@@ -161,7 +161,7 @@ In the **test** stage, GitLab runs various checks on the application:
- The `code_quality` job checks the code quality and is allowed to fail - The `code_quality` job checks the code quality and is allowed to fail
([Auto Code Quality](index.md#auto-code-quality-starter)) **[STARTER]** ([Auto Code Quality](index.md#auto-code-quality-starter)) **[STARTER]**
- The `container_scanning` job checks the Docker container if it has any - The `container_scanning` job checks the Docker container if it has any
vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning)) vulnerabilities and is allowed to fail ([Auto Container Scanning](index.md#auto-container-scanning-ultimate))
- The `dependency_scanning` job checks if the application has any dependencies - The `dependency_scanning` job checks if the application has any dependencies
susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning-ultimate)) **[ULTIMATE]** susceptible to vulnerabilities and is allowed to fail ([Auto Dependency Scanning](index.md#auto-dependency-scanning-ultimate)) **[ULTIMATE]**
- The `sast` job runs static analysis on the current code to check for potential - The `sast` job runs static analysis on the current code to check for potential
......
...@@ -12,7 +12,7 @@ two open source tools for Vulnerability Static Analysis for containers. ...@@ -12,7 +12,7 @@ two open source tools for Vulnerability Static Analysis for containers.
You can take advantage of Container Scanning by either [including the CI job](#including-the-provided-template) in You can take advantage of Container Scanning by either [including the CI job](#including-the-provided-template) in
your existing `.gitlab-ci.yml` file or by implicitly using your existing `.gitlab-ci.yml` file or by implicitly using
[Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning) [Auto Container Scanning](../../../topics/autodevops/index.md#auto-container-scanning-ultimate)
that is provided by [Auto DevOps](../../../topics/autodevops/index.md). that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
GitLab checks the Container Scanning report, compares the found vulnerabilities GitLab checks the Container Scanning report, compares the found vulnerabilities
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment