Gates
What a gate is, how Prodgator tells deployment environments apart, and what you can attach to a gate.
Availability
A gate is a named group of deployment environments that share release configuration: approvers, release policies, approval settings and notifications. A deployment environment is a provider's environment in one repository (for example the GitHub environment in ), optionally narrowed to one workflow. A gate may hold several deployment environments, and a deployment environment may belong to several gates.
Gates were called environments (and the page was called Environments) before. The name changed so a gate is never confused with a provider's deployment environment. Old links under still work and open the same place under .
Environment names are not unique
A deployment environment is identified by its provider, its repository, its workflow (when it is narrowed to one) and its name. The workflow is its file, for example , which is unique in a repository. The workflow's display name () is only a label, so two workflows that share a display name stay apart. The environment name alone is not enough either: in and in are two deployment environments, and so are the environments of two workflow files when you narrow them.
In links and the API, a deployment environment is written as , for example . Keys saved before Prodgator added the provider and the workflow file () still work.
- Links from a run, a deployment, a board cell and a notification always open the one deployment environment they are about.
- To treat several deployment environments that share a name as one, link each of them to a gate. You can link as many as you like, from different repositories and workflows.
- Filtering by name is still available, and always says so: Every environment named production-release on the deployment tabs lists that name in every repository and workflow.
- Name patterns stay available where you choose them on purpose: auto-include patterns, policy binding patterns and compliance policy environment names. Each one matches by name in the repositories its pattern covers. The Auto-include panel lists the deployment environments its patterns match today.
A repository keeps its identity when it is renamed or transferred (see Renamed and transferred repositories).
What attaches to a gate
When you group deployment environments behind a gate, you can attach:
- Release policies that govern deployments to those deployment environments
- Approver groups notified when a release waits for approval
- Approval settings that control how reviews and self-approval work across the deployment environments
- Notification routing to send approval requests to approver groups
- Promotion order to display the gates as steps (Development to Staging to Production, for example)
The same settings can be set on one deployment environment directly. When settings come from several sources, everything applies:
- A release needs all required approvals and must pass all policies.
- Reviewer forwarding is off if any source turns it off, and on if a source turns it on and none turns it off. When no source sets it, your organization's default applies (on unless an admin changed it).
- Self-approval is on only if a source turns it on and none turns it off. When no source sets it, your organization's default applies (off unless an admin changed it). It only counts where a policy rule allows self-approval.
- Admin overrides of release policies are allowed only when the organization allows them and no source turns them off (see Admin override).
- Approver groups from every source are combined.
An admin can exclude a deployment environment from a gate's policies with a reason recorded in the audit log.
Protected environments
A deployment environment is protected when at least one gate covers it, by a link or an auto-include pattern, and it is not excluded from that gate. Prodgator never decides this from an environment's name: an environment named that no gate covers is not protected, and an environment named that a gate covers is.
Metrics about deployments count protected environments only:
- SPACE metrics: change failure rate and protected deployments
- Compliance: the deploy frequency SLA
- Ask Prodgator: each deployment it lists says whether it went to a protected environment
Metrics over past days use your gates as they are today, so linking a deployment environment to a gate also counts its earlier deployments. Until a gate protects at least one deployment environment, these metrics stay empty and link here.
Whether the provider waits for Prodgator before it deploys (a deployment protection rule on GitHub, a protected environment on GitLab, a check on Azure DevOps) is set up per provider on the gate's page. It is not part of this rule, because Prodgator can only see it for some providers.
Terminology
| Term | Meaning |
|---|---|
| Gate | A named group of deployment environments with shared release configuration (approvers, policies, approval settings, notifications). Formerly called an environment or environment group |
| Protected environment | A deployment environment that a gate covers and does not exclude. Deployment metrics count only these |
| Deployment environment | A provider's environment in one repository (for example the GitHub environment in ), optionally narrowed to one workflow. Identified by provider, repository, workflow and name, never by the name alone |
| Release | A version (commit or release name) moving through gates and deployment environments |
Related
The Gates page
The gate list, one gate's page and the deployment tabs.
Set up a gate
Promotion order, auto-include patterns and membership.
Approval settings
Self-approval and reviewer forwarding for the organization, a gate or a deployment environment.
Approve deployments
Prodgator's protection rule, required reviewers and bulk actions.
Bypassed deployments
What happens when a deployment skips its protection rules.
Roll back a deployment
Re-run an earlier successful deployment.
Release policies
Rules a deployment must pass before it goes out.