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