# Review and deploy

Deployment publishes configuration to `main`. It is complete only when the intended workers are running it.

[How Git versions configuration and workers follow main →](/docs/git/configuration)

*Diagram: From a draft to running workers. Draft changes go to review. Review can send them back for revision. Approval and deployment publish a commit on main. Each worker fetches main and reports its running commit.*

Review the diff and test results before approval. Each worker fetches main independently; check its running commit to confirm adoption.

## Open for review

1.  Save the branch and [run its tests](/build#test-heading).
2.  Select **Open for review** in the branch bar, check the title, description and test results it fills in, and open the change.
3.  If main has moved, bring the branch current and recheck the diff and tests before deployment.

## Review the evidence

-   The diff (the comparison with the deployed version) contains only intended edits.
-   Preview output has the intended fields and types, and the tests pass.
-   You have checked affected routes and destinations.
-   Samples and changes contain no exposed credentials.
-   Each affected pipeline and route has tests for the records it should keep, change, or drop. Add missing tests before deployment.
-   The review includes shared configuration and other worker groups.
-   Required secret versions and external credentials are available.
-   You have identified a known-good configuration and recovery plan.

## Deploy and verify

1.  Deploy the reviewed change to main.
2.  Record the deployed main commit, then open Status and compare it with each intended worker's Commit.
3.  Investigate deployment failures and confirm destination output before calling the change complete.

| Evidence | What it proves |
| --- | --- |
| Commit on main | Configuration was published |
| Recent heartbeat | Worker recently contacted the leader; check the running commit separately |
| Worker Commit matches deployed main | Worker reports running that configuration; also compare it with the commit you deployed |
| Expected destination output | The checked data path behaves as intended |

## Roll back

Use Branches → History → **Roll back to here**. Check secret versions and fleet-wide impact before confirming; verify worker adoption afterward.

See [the rollback procedure](/docs/operations#changes). A configuration rollback is not a binary downgrade.