Some environments, such as
production, should be protected so that only qualified people can affect them. This is particular important for manual actions such as
deploy to production, but could apply to automatic actions as well. This is similar, but slightly different than protected branches. Depending on how protected branches evolves, protecting environments may not be necessary. Or vice versa.
- Use an interface similar to protected branches
User should be able to:
- Determine at a glance if an environment is protected or not
- Once you drill down into the environment, see who has permission to deploy to this environment
- If user has the proper role/access, protect/unprotect and environment
- If user has proper role/access, add roles/users to the "allowed to deploy" list
Environments can be used for different scopes, so some of them are just for testing while others are for production. As deploy jobs could be raised by different users with different roles, it is very important that specific environments are "protected" to avoid unauthorized people to affect them. This feature ensures that only people with the right privileges can deploy code to the "protected" environments, keeping them safe.
owner role should be able to deploy to environment (same roles that can access the terminal by default)
|See deploy board||Y||Y||Y|
|See pod logs||Y||Y||Y|
|Configure metrics & alerts||Y||Y|
|Deploy to environment||Y||Y|
Within project CI/CD settings, we'll include another section for Protect Environments settings. This will allow users to choose an environment to protect or to create a wildcard. An environment can be protected by selecting
Maintainers, an individual user(s), or a group(s) that is shared with the project. We can also include
No one which should deselect other options that were selected.
No one, all other options are deselected.
- If you have
No oneselected, and select another criteria,
No onshould be deselected
Maintainers, input reads
1 Group, input reads
1 role, 1 group
2 users, input reads
1 role, 1 group, 2 users
1 user, input reads
2 groups, 1 user
2 Groups, input reads
1 user, input reads
|Protected environments settings||Dropdown|
To reduce scope, we can choose to not include
No one in the MVP since the current functionality for protected branches is partially broken for
Wildcards are handled the same as protected branches:
|Protected environment wildcard||Overview view|
Environment overview page
Within the environments page, we will show a badge that reads
protected. This is the same functionality that is used for protected environments. Users without permissions won't see the deploy options.
production will be protected by default, and users will have the ability to change or remove the protection (same as
master on protected branches.
|With permissions||Without permissions|
If a user doesn't have permissions to deploy to a particular environment, the CI job will fail.
There will be no trace as the job won't be picked up by the runner.