Deployments
A deployment turns one commit into one running revision of one web service. Kuppit builds a container image from the commit, starts a revision from it, waits for the revision to be healthy, and only then moves traffic to it. Until that last step, whatever was serving keeps serving.
What starts a deployment
| Trigger | When |
|---|---|
| Git push | A push to the branch an environment deploys: the production branch for Production, its own branch for a named environment. Every web service in that environment deploys. |
| Pull request | A pull request opened, reopened or pushed to. Its preview environment deploys. |
| Manual | Deploy on the service's page, which deploys the head of the environment's branch. |
| Redeploy | Redeploy this commit on a deployment: the same commit, built again with today's settings and variables. |
| Rollback | Roll back to this deployment on a previous one: the image it already built, deployed again. |
Redeploy and rollback are described on their own page.
Statuses
A deployment's status is what Kuppit is doing with it, or how it ended.
| Status | Meaning |
|---|---|
| Queued | Accepted and waiting for a builder. |
| Building | Turning the commit into a container image. |
| Deploying | Kuppit is provisioning and promoting the new revision. |
| Live | Serving production traffic. |
| Previous | Superseded by a newer deployment. |
| Failed | Stopped before reaching production. Traffic was not moved. |
| Cancelling | Stopping. Whatever had already started is being wound down. |
| Cancelled | Stopped on request. It never took traffic. |
Exactly one deployment of a service is Live. When a newer one goes live, the old one becomes Previous; it keeps its outcome, and it stays a rollback candidate because nothing rewrites it.
Status is about one deployment. Whether the service is serving is a separate question with its own answer, service health: a service can show Building on a new deployment and Healthy at the same time, because the previous revision is still up.
The phases
The deployment page shows the work as five phases, each with what Kuppit is doing:
| Phase | What happens |
|---|---|
| Analyzing source | Reading the repository and resolving the build. |
| Building image | Creating the production container image. See Builds. |
| Starting revision | Provisioning compute for the new revision. A revision that needs a database still being created waits here, as Waiting for a resource. |
| Health check | Waiting for the revision to report healthy. A server that does not listen on PORT fails here. |
| Going live | Moving production traffic to the new revision. |
A failed phase says why, in words meant for a developer, with the build or runtime logs behind it. See when a deployment fails.
One at a time
A service runs one deployment at a time. A second Deploy, redeploy or rollback while one is in flight is refused rather than queued: cancel the one in progress first, and Kuppit's button says so.
A new push is the exception. Pushing again while a push's deployment is still building supersedes it: the older deployment stops, shows as Previous without ever having gone live, and the newer commit takes its place. Only pushes and pull requests supersede; a rollback never cancels the deployment you are rolling back from.
Cancelling
A deployment that has not reached Going live can be cancelled, from Cancel deployment in its menu. Kuppit stops it and asks the builder to abandon it, and it will never take traffic. Whatever is serving now is unaffected.
A deployment that is already moving traffic cannot be cancelled. Roll back to the previous one instead.
What a deployment records
Every deployment is immutable. It records the commit, the build settings it was resolved with, and the variables it was prepared with, so that a Previous deployment can be rolled back to exactly as it was, changed variables and all. Nothing edits a deployment after the fact: cancelling, redeploying and rolling back each create a new one.