Set up a gate
Order gates, include deployment environments by pattern, and keep membership right when repositories are renamed.
Availability
Who can use this: Release manager and Org admin. See Roles.
Create a gate with New gate on the Gates page's Gates tab, then link deployment environments to it by hand or with patterns.
Promotion order
When you set a promotion order on gates, the board shows them left to right in that order (Development, Staging, Production, for example). Gates without a promotion order come last, in name order. The order also shows as numbered steps on the Gates page.
Auto-include patterns
When linking deployment environments, you can give patterns that include matching deployment environments automatically:
- Repository pattern: always , with wildcards: , , , or for every repository
- Environment pattern: , , or for every deployment environment
matches any characters and matches one character. Matching ignores case. Deployment environments you linked by hand stay even if they no longer match a pattern. The Auto-include panel lists the deployment environments each pattern matches today. A pattern such as with matches that name in every repository, so link deployment environments one by one when you mean specific ones.
An exclusion does not remove a deployment environment from the gate. It stops that gate's policies from applying to it, and needs that permission and a reason that goes to the audit log.
Environments from other CI
A pipeline in CircleCI, Buildkite, Jenkins or another CI system can ask a gate for approval before it deploys (see Any CI). The gate must cover the environment the pipeline names.
To link one, open the gate's link dialog and choose Other CI as the source of the deployment environment:
- Repository: as the CI system reports it, as , for example . A repository URL works too, but not one with a user name or password.
- Environment: the name the pipeline passes to . It cannot contain , or .
- CI system (optional): the id the pipeline sends, for example . Leave it empty and the link covers every CI system for that repository and environment.
Auto-include patterns work for these environments only when the repository pattern starts with , for example . The rest is matched against with the same wildcards. A pattern without (such as ) never covers an environment from other CI, and a pattern with it never covers a provider's repository. A pipeline that names an environment no gate covers is refused, and Prodgator remembers the name so the link dialog can offer it.
Approvers, approval settings and policies apply as for any deployment. Self-approval rules cannot be enforced, because the person the pipeline names as the actor is self-reported. Prodgator cannot reach the CI system, so it cannot roll back or cancel an Other CI deployment; do that in your CI system. The deployment is marked self-reported, because the pipeline's own word is the only evidence of what ran.
Membership
A deployment environment's membership in a gate comes from:
- Explicit links (added by someone who can change gates)
- Auto-include patterns (added automatically)
- Workflow-narrowed members (the environment in only when the workflow file is ; also works for GitHub Actions)
A run's deployment is governed by any gate it matches, plus direct settings on that deployment environment.
Renamed and transferred repositories
Prodgator tracks each repository by the provider's repository id, which stays the same when a repository is renamed or moved to another owner. After a rename, the deployment environments of the old and new names show as one entry under the current name, with the old name listed under it ("Also seen as").
Links, exclusions, direct settings and policies you set up under the old name keep applying. New links and settings are saved under the current name. Deployments stored before Prodgator recorded repository ids match by name only until the repository runs again.
Which deployment environments are listed
The Deployment environments list only shows deployment environments in your tracked pipeline runs. An entry drops off the list when:
- It has had no deployment for your plan's data retention period (90 days on Business, 365 on Enterprise), or
- Its repository's provider connection was removed from Prodgator.
Dropped entries are not offered when you link deployment environments. If a dropped entry still has direct settings, a gate link, an exclusion or a policy attached to it, it stays in a Stale section with the date it was last seen (or "Repository not connected").
Nothing is deleted on its own: someone who can change gates can choose Clean up to remove its direct settings, exclusions and gate links, under its current and old repository names. A policy attached directly to it must be detached on the policy first. Deployments and history are kept.
The Gates page
The Gates page's tabs, the gate list, one gate's page, and the deployment tabs for pending, active and past deployments.
Enforce provenance without an approval
Count deployment environments as protected and enforce provenance rules automatically, while only a release environment needs a person.