Change management
Nothing deploys on its own: Context ships releases, and your admin decides when each one is deployed.
Release and change process
| Area | What happens | Who decides |
|---|---|---|
| Notification | Release notes come with each release and appear in your admin console. Larger batched changes and the changelog come monthly. | Context |
| Testing | Every change runs Context’s automated test suites before it ships. In your cluster, preflight checks (cluster version, nodes, memory, CPU, storage) must pass before a deploy continues. | Context, then automatic checks in your cluster |
| Approval | Nothing deploys on its own. Your admin chooses when to deploy in the admin console. | Your admin |
| Emergency changes | An urgent fix ships as an out-of-cycle release on the same channel and still waits for your admin to deploy. Priority 1 incidents page Context’s on-call through PagerDuty (see Get help). | Your admin |
| Rollback | Every deployment is versioned, like a Helm release, through Replicated KOTS. The admin console rolls back code changes and deployment configuration changes to an earlier version. Database changes are backward-compatible and are not rolled back. | Your admin |
How releases arrive
Releases reach your deployment through Replicated. Each release bundles a version of the application with its notes.