Begin writing Overview section
This commit is contained in:
parent
6715091bbc
commit
8666fd7613
|
@ -3,20 +3,38 @@
|
|||
>**Note:**
|
||||
Introduced in GitLab 8.9.
|
||||
|
||||
During the development of a software there can be many stages until it's ready
|
||||
for public consumption. You sure want to first see your code in a testing or
|
||||
staging environment before you release it to the public. That way you can
|
||||
prevent bugs not only in your software, but in the deployment process as well.
|
||||
During the development of a software, there can be many stages until it's ready
|
||||
for public consumption. You sure want to first test your code and then deploy it
|
||||
in a testing or staging environment before you release it to the public. That
|
||||
way you can prevent bugs not only in your software, but in the deployment
|
||||
process as well.
|
||||
|
||||
With environments you can control the Continuous Deployment of your software all
|
||||
In case you use GitLab CI to not only test or build your project, but also
|
||||
deploy it in your infrastructure, GitLab provides a way to track your deployments
|
||||
so you always know what is currently being deployed on your servers. With
|
||||
environments you can control the Continuous Deployment of your software all
|
||||
within GitLab. All you need to do is define them in your project's
|
||||
[`.gitlab-ci.yml`][yaml].
|
||||
[`.gitlab-ci.yml`][yaml]. GitLab provides a full history of your deployments per
|
||||
every environment.
|
||||
|
||||
In the following sections, we'll see how that works.
|
||||
## Overview
|
||||
|
||||
## An environments example
|
||||
Deployments are created when [jobs] deploy versions of code to environments,
|
||||
so every environment can have one or more deployments. GitLab keeps track of
|
||||
your deployments, so you always know what is currently being deployed on your
|
||||
servers.
|
||||
|
||||
Let's assume that you have
|
||||
Environments are like tags for your CI jobs, describing where code gets deployed.
|
||||
CI/CD [Pipelines] usually have one or more [jobs] that deploy to an environment.
|
||||
You can think of names such as testing, staging or production.
|
||||
|
||||
Defining environments in a project's `.gitlab-ci.yml` lets developers track
|
||||
[deployments] to these environments.
|
||||
|
||||
The environments page can only be viewed by Reporters and above. For more
|
||||
information on the permissions, see the [permissions documentation][permissions].
|
||||
|
||||
Let's assume that you have:
|
||||
|
||||
1. Define the environments in `.gitlab-ci.yml`
|
||||
1. Push the repository to GitLab
|
||||
|
@ -41,18 +59,6 @@ View commit SHA that triggered the deployment
|
|||
View branch the deployment was based on
|
||||
View time ago the deployment was performed
|
||||
|
||||
Environments are like tags for your CI jobs, describing where code gets deployed.
|
||||
|
||||
You can think of names such as testing, staging or production.
|
||||
|
||||
CI/CD [Pipelines] usually have one or more [jobs] that deploy to an environment.
|
||||
|
||||
Defining environments in a project's `.gitlab-ci.yml` lets developers track
|
||||
[deployments] to these environments.
|
||||
|
||||
The environments page can only be viewed by Reporters and above. For more
|
||||
information on the permissions, see the [permissions documentation][permissions].
|
||||
|
||||
### Defining environments
|
||||
|
||||
While you can create and delete environments manually in the web interface, we
|
||||
|
@ -129,13 +135,6 @@ stop_review:
|
|||
action: stop
|
||||
```
|
||||
|
||||
## The relationship between deployments and environments
|
||||
|
||||
Deployments are created when [jobs] deploy versions of code to [environments],
|
||||
so every environment can have one or more deployments. GitLab keeps track of
|
||||
your deployments, so you always know what is currently being deployed on your
|
||||
servers.
|
||||
|
||||
### View the deployment history
|
||||
|
||||
Clicking on an environment will show the history of deployments.
|
||||
|
|
|
@ -573,8 +573,7 @@ In its simplest form, the `environment` keyword can be defined like:
|
|||
deploy to production:
|
||||
stage: deploy
|
||||
script: git push production HEAD:master
|
||||
environment:
|
||||
name: production
|
||||
environment: production
|
||||
```
|
||||
|
||||
In the above example, the `deploy to production` job will be marked as doing a
|
||||
|
@ -674,61 +673,6 @@ The `stop_review_app` job is **required** to have the following keywords defined
|
|||
- `environment:name`
|
||||
- `environment:action`
|
||||
|
||||
#### environment:name
|
||||
|
||||
#### environment:url
|
||||
|
||||
Optional.
|
||||
|
||||
#### environment:on_stop
|
||||
|
||||
> [Introduced][ce-6669] in GitLab 8.13.
|
||||
|
||||
Closing environments can be achieved with the `on_stop` keyword defined under
|
||||
`environment`. It declares a different job that has to be run in order to close
|
||||
the environment.
|
||||
|
||||
This job is required to have the following keywords defined:
|
||||
|
||||
- `when` - [reference](#when)
|
||||
- `environment:name`
|
||||
- `environment:action` - reference below
|
||||
|
||||
See below for an example.
|
||||
|
||||
#### environment:action
|
||||
|
||||
> [Introduced][ce-6669] in GitLab 8.13.
|
||||
|
||||
The `action` keyword is to be used in conjunction with `on_stop` and is defined
|
||||
in the job that depends on the one that was called from.
|
||||
|
||||
Take for instance:
|
||||
|
||||
```yaml
|
||||
review:
|
||||
stage: deploy
|
||||
script: make deploy-app
|
||||
environment:
|
||||
name: review
|
||||
on_stop: stop_review
|
||||
|
||||
stop_review:
|
||||
stage: deploy
|
||||
script: make delete-app
|
||||
when: manual
|
||||
environment:
|
||||
name: review
|
||||
action: stop
|
||||
```
|
||||
|
||||
In the above example we set up the `review` job to deploy to the `review`
|
||||
environment, and we also defined a new `stop_review` job under `on_stop`.
|
||||
Once the `review` job is successfully finished, it will trigger the `stop_review`
|
||||
job based on what is defined under `when`. In this case we set it up to `manual`
|
||||
so it will need a [manual action](#manual-actions) via GitLab's web interface
|
||||
in order to run.
|
||||
|
||||
#### dynamic environments
|
||||
|
||||
> [Introduced][ce-6323] in GitLab 8.12 and GitLab Runner 1.6.
|
||||
|
@ -737,9 +681,7 @@ in order to run.
|
|||
These parameters can use any of the defined [CI variables](#variables)
|
||||
(including predefined, secure variables and `.gitlab-ci.yml` variables).
|
||||
|
||||
---
|
||||
|
||||
**Example configurations**
|
||||
For example:
|
||||
|
||||
```
|
||||
deploy as review app:
|
||||
|
|
Loading…
Reference in New Issue