@@ -187,7 +187,7 @@ The microservice project setup can be improved by [Multi-Project Deployment Pipe
- Environments can be created within the application projects. It gives more visibility of environments for developers.
- Deployment Project can be managed under Operator group. More segregation of duties.
- Users don't need to set up [RBAC to restrict CI/CD jobs](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html#restrict-project-and-group-access-by-using-impersonation).
- This is especially helpful for [dynamic environments](https://docs.gitlab.com/ee/ci/environments/index.html#create-a-dynamic-environment) like review apps.
- This is especially helpful for [dynamic environments](https://docs.gitlab.com/ee/ci/environments/index.html#create-a-dynamic-environment).
@@ -41,14 +41,6 @@ Currently there are two main uses for the .org environment:
This is a critical piece of infrastructure that is always growing in size due to build artifacts. There are discussions to make a new build server where nightly CE/EE builds can be deployed or to move the infra repos to a new host that would be a separate (not gitlab.com) EE instance. Although the environment has dev in its domain name, don't refer to it as dev, since that could be confused with a local development environment.
| Review apps | various | Test proposal | on commit | Fixture | Review app owner |
Ephemeral app environments that are created dynamically every time you push a new branch up to GitLab, and they're automatically deleted when the branch is deleted. Single container with limited access.