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.
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/*`,
