Environments have a number of advantages both in terms of security and UX.
Notably we are able to see a list of deployments to environments with a direct link to the environment URL if present:
This is also accessible via API and there are dedicated webhook events for new deployments which are useful for internal automation; deployments to environments also can be restricted to specific branches and can have their own secrets and variables allowing us in future to further DRY up our workflows (I've not done that here because we're still in the process of just switching our existing workflows to using environments, and I don't want to do too much too fast).
Environments are also automatically created if they don't already exist the first time a deployment occurs meaning there are no additional setup steps required by this change.
Note that this does impact OIDC-based workflows as environments take priority over other refs so this will change the OIDC claim from e.g. "ref:refs/heads/production" to environment:production - this is actually a positive in the long-run as it means branch:env mapping is fully managed in the application codebase rather at the infrastructure level.
Environments have a number of advantages both in terms of security and UX.
Notably we are able to see a list of deployments to environments with a direct link to the environment URL if present:
This is also accessible via API and there are dedicated webhook events for new deployments which are useful for internal automation; deployments to environments also can be restricted to specific branches and can have their own secrets and variables allowing us in future to further DRY up our workflows (I've not done that here because we're still in the process of just switching our existing workflows to using environments, and I don't want to do too much too fast).
Environments are also automatically created if they don't already exist the first time a deployment occurs meaning there are no additional setup steps required by this change.
Note that this does impact OIDC-based workflows as environments take priority over other refs so this will change the OIDC claim from e.g.
"ref:refs/heads/production"toenvironment:production- this is actually a positive in the long-run as it means branch:env mapping is fully managed in the application codebase rather at the infrastructure level.