Dynamic environments aka review apps
This issue describes dynamic environments implementation, mostly to be used with dynamically create applications. These application will be mostly used for Review Apps.
- We will allow to create dynamic environments from
.gitlab-ci.yml, by allowing to specify environment variables:
- We will use multiple deployments of the same application per environment,
- The URL will be assigned to environment on the creation, and updated later if necessary,
- The URL will be specified in
.gitlab-ci.yml, possibly introducing regexp for getting an URL from build log if required,
- We need some form to distinguish between production/staging and review app environment,
- 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.
review_apps: environment: name: review/$CI_BUILD_REF_NAME url: http://$CI_BUILD_REF_NAME.review.gitlab.com/
- We are limited to use only CI predefined variables, since this is not easy task to pass the URL from build,
- I do prefer nested
url:since this allows us in the future to extend that with more
environment:configuration or constraints, like:
access_levelof user allowed to use that.
- Following the problem from (1) we can extend
regexpthat will be used to fish a URL from build log.
Distinguish between production and review apps
I feel that we need to be forward thinking and make this distinction. I thought about:
- Introducing a predefined
- Introducing a user configured
Environment Types, similar to previous, but with full fledged management,
@markpundsack proposed to do use
Stagesof Pipeline to mark environment type,
But all of this doesn't feel right. So I thought that we should follow a principle: convention over configuration.
Convention over configuration
We would expect the environments to be of
- This would allow us to have a clear distinction between different environment types:
- Since we use a folder structure we could group all environments by
typeand strip that from environment name,
- We would be aware of some of these types and for example for
review-appsshow them differently in context of Merge Requests, ex. calculating
deployed agoa little differently.
- We could easily group all
typesacross from group from all projects.
type/name also plays nice with
Runners, because we can limit their usage:
- We could extend the resources with a field that would allow us to filter for what types it can be used, ex.:
- We could limit runners to be used only by