parent
17cf2adf04
commit
46a7e681e0
Binary file not shown.
After Width: | Height: | Size: 28 KiB |
|
@ -19,8 +19,19 @@ any way you'd like.
|
|||
|
||||
## Overview
|
||||
|
||||
Simply put, a Review App is a mapping of
|
||||
a branch with an environment as there is a 1:1 relation between them.
|
||||
Simply put, a Review App is a mapping of a branch with an environment as there
|
||||
is a 1:1 relation between them.
|
||||
|
||||
Here's an example of what it looks like when viewing a merge request with a
|
||||
dynamically set environment.
|
||||
|
||||
![Review App in merge request](img/review_apps_preview_in_mr.png)
|
||||
|
||||
In the image above you can see that the `add-new-line` branch was successfully
|
||||
built and deployed under a dynamic environment and can be previewed with an
|
||||
also dynamically URL.
|
||||
|
||||
---
|
||||
|
||||
To get a better understanding of Review Apps, you must first learn how
|
||||
environments and deployments work. The following docs will help you grasp that
|
||||
|
@ -34,9 +45,9 @@ knowledge:
|
|||
how environments work.
|
||||
1. Additionally, find out about [manual actions][] and how you can use them to
|
||||
deploy to critical environments like production with the push of a button.
|
||||
1. And as a last step, follow the [NGINX example tutorial][app-nginx] which will
|
||||
1. And as a last step, follow the [example tutorials](#examples) which will
|
||||
guide you step by step to set up the infrastructure and make use of
|
||||
Review Apps with a simple HTML site and NGINX.
|
||||
Review Apps.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
@ -66,7 +77,18 @@ From there on, you would follow the branched Git flow:
|
|||
1. Click on the link that's present in the MR related to the branch and see the
|
||||
changes live.
|
||||
|
||||
### Limitations
|
||||
## Distinguish between production and review apps
|
||||
|
||||
1. We need some form to distinguish between production/staging and review app environment,
|
||||
|
||||
- Are dynamic environments distinguishable by the slash in `environment:url`?
|
||||
|
||||
We would expect the environments to be of `type/name`:
|
||||
|
||||
1. This would allow us to have a clear distinction between different environment types: `production/gitlab.com`, `staging/dev`, `review-apps/feature/branch`,
|
||||
3. We would be aware of some of these types and for example for `review-apps` show them differently in context of Merge Requests, ex. calculating `deployed ago` a little differently.
|
||||
|
||||
## Limitations
|
||||
|
||||
We are limited to use only [CI predefined variables][variables].
|
||||
|
||||
|
@ -83,33 +105,6 @@ And below is a soon to be added examples list:
|
|||
- Use on Heroku with dpl
|
||||
- Use with OpenShift/kubernetes
|
||||
|
||||
## Assumptions
|
||||
|
||||
1. We will allow to create dynamic environments from `.gitlab-ci.yml`, by allowing to specify environment variables: `review_apps_${CI_BUILD_REF_NAME}`,
|
||||
1. We will use multiple deployments of the same application per environment,
|
||||
1. The URL will be assigned to environment on the creation, and updated later if necessary,
|
||||
1. The URL will be specified in `.gitlab-ci.yml`, possibly introducing regexp for getting an URL from build log if required,
|
||||
1. We need some form to distinguish between production/staging and review app environment,
|
||||
1. We don't try to manage life cycle of deployments in the first iteration, possibly we will extend a Pipeline to add jobs that will be responsible either for cleaning up or removing old deployments and closing environments.
|
||||
|
||||
## Distinguish between production and review apps
|
||||
|
||||
- Are dynamic environments distinguishable by the slash in `environment:url`?
|
||||
|
||||
### Convention over configuration
|
||||
|
||||
We would expect the environments to be of `type/name`:
|
||||
|
||||
1. This would allow us to have a clear distinction between different environment types: `production/gitlab.com`, `staging/dev`, `review-apps/feature/branch`,
|
||||
2. Since we use a folder structure we could group all environments by `type` and strip that from environment name,
|
||||
3. We would be aware of some of these types and for example for `review-apps` show them differently in context of Merge Requests, ex. calculating `deployed ago` a little differently.
|
||||
3. We could easily group all `types` across from group from all projects.
|
||||
|
||||
The `type/name` also plays nice with `Variables` and `Runners`, because we can limit their usage:
|
||||
|
||||
1. We could extend the resources with a field that would allow us to filter for what types it can be used, ex.: `production/*` or `review-apps/*`
|
||||
2. We could limit runners to be used only by `review-apps/*`,
|
||||
|
||||
[app-nginx]: nginx_guide.md
|
||||
[ce-21971]: https://gitlab.com/gitlab-org/gitlab-ce/issues/21971
|
||||
[dynamic environments]: ../environments.md#dynamic-environments
|
||||
|
|
Loading…
Reference in New Issue