Documentation

Environment and service connection checks

Approvals, branch control, business hours, exclusive locks and the rest, applied across projects.

The Projects tab configures the checks that gate deployments. Azure DevOps calls these approvals and checks, and configures them one environment at a time; Charter applies the same set across every project you select.

Checks can be attached to environments and to service connections. The same check types are available for both.

The checks Charter supports

Check	What it does	Runs as
Approvals	Named approvers must approve before the stage runs.	Pre-check approval
Branch control	Only branches linked to the run may deploy.	Static
Required template	Only pipelines extending a listed YAML template may run.	Static
Business Hours	The deployment may only start inside a time window.	Dynamic
Invoke Azure Function	Calls a function and gates on its response.	Dynamic
Invoke REST API	Calls an API and gates on its response.	Dynamic
Exclusive Lock	One stage at a time may use the resource.	Exclusive lock

Azure DevOps runs checks in categories, in that order, and in parallel within a category. The category is fixed per check type and is the only ordering Charter can express.

Business Hours

Pick the days, a start and end time on a 24-hour clock, and a time zone.

The time zone is a Windows time zone identifier — UTC, W. Europe Standard Time, Pacific Standard Time — which is what Azure DevOps stores. Charter offers the full list of 142 identifiers as a searchable picker, labelled with each zone's offset.

The offsets shown are standard time, so a zone that observes daylight saving reads an hour out for part of the year. The identifier is what gets stored either way, and Azure DevOps handles the seasonal shift itself.

The picker also accepts a typed value. Azure DevOps publishes no API for this list, so Charter ships a snapshot of it — if Microsoft adds a zone, you can still enter it by hand rather than waiting for an update.

Approvals

Approvers are resolved against the project's teams and members. Because an approver must exist in the project being written to, the same approval applied across projects resolves each name per project rather than carrying an identifier that would only be valid in one.

Service connections

Service connection checks work the same way, with one difference: a connection is referenced by name, not by identifier. Identifiers are per project, so a configuration carrying one would break in every project except the one it came from.

One check per resource, for some types

Azure DevOps stores no display name for approvals or exclusive locks, so it cannot tell two of them apart on the same resource. For those types Charter updates the existing check rather than adding a second one.