Skip to content
Sencai.docs

Deployments

Operations → Deployments (/gravity/operations/deployments) is a tracker for deployments your own CI/CD pipeline performs - Sencai doesn’t run your build or deploy step, it records what happened so deployment history sits next to the incidents and changes it’s related to.

What a deployment record represents

Section titled “What a deployment record represents”

A deployment record is one CI/CD run against one service: which service, which environment (development, staging, production, or preview), a version identifier, and a strategy (Blue/Green, Rolling, or Canary) if your pipeline reports one. Records are shown as a timeline, newest first, and can be filtered to a single service.

Creating and tracking deployments

Section titled “Creating and tracking deployments”

Deployment records are created by your CI/CD pipeline pushing events to a dedicated webhook endpoint, authenticated with a bearer token you configure for the integration - the app’s Webhook Setup panel on this page shows the exact endpoint and an example request for your environment. Your pipeline reports:

  • Status transitions - pending → in_progress/running → a terminal status (completed/success, failed, rolled_back, or cancelled)
  • Duration, who deployed, and an optional deployment URL and error log

A record with a Blue/Green strategy additionally shows a live traffic-split percentage as your pipeline reports it.

Only your active organization’s deployments are shown - switch organizations in the app to see another one’s history. Use the service filter dropdown above the timeline to narrow a busy history down to one service’s deployments.

Reading a deployment entry

Section titled “Reading a deployment entry”

Each entry in the timeline shows the service name, a status chip, an environment chip, and (if reported) a version chip and strategy badge, plus who deployed and how long it took. A failed, rolled-back, or cancelled deployment additionally shows an expandable Error Log panel with whatever detail your pipeline reported.

Which image a deployment shipped

Section titled “Which image a deployment shipped”

A deployment record can carry the image it shipped: its reference (image_ref) and its digest (image_digest). These two fields are accepted when a deployment is created or updated through the Deployments API with a signed-in credential. The CI webhook endpoint described above does not accept them (it answers 400), so a record created only by the webhook shows no image.

When a record has an image, the entry shows an Image line with the reference and the shortened digest. If the digest is one of the images in your organization’s private registry and you can read the registry, the entry also shows that image’s signature and scan badges - the same ones as in the registry. The scan counts need access to security findings. If the digest is not an image in your registry, the entry says there is no signature or scan information for it (that is not the same as “unsigned”), and if only a tag was recorded, it warns that no digest was recorded and the deployment cannot be verified, because a tag can point to a different image tomorrow. Nothing here blocks a deployment: the badges report, they do not gate. See Image signing and verification to check the signature yourself.

Deployments that Sencai makes for you

Section titled “Deployments that Sencai makes for you”

When you create an instance with a container from the instance wizard, Sencai creates the deployment record itself - see Deploy a container to a new instance. The entry names the server and links to it (“Record of a container deployed on a server”), always carries the image reference and digest, and its status follows what the server reports: pending, in progress, then success or failed. Because the record is what the server reported, it cannot be edited or deleted by hand, and a CI webhook that happens to use the same name does not overwrite it - it gets a record of its own.

The signature and scan badges follow the rules of the previous section. When you may not read the registry, the entry says it cannot show them, which is not the same as “unsigned”. When the registry could not be read just now, it says that instead and asks you to reload.

Actions on a deployment

Section titled “Actions on a deployment”

Two actions are available on a deployment that isn’t yet in a terminal state:

  • Switch Traffic - available for Blue/Green deployments only. This marks the deployment complete with traffic fully switched.
  • Rollback - available on any non-terminal deployment. This marks the deployment as rolled back.

A deployment linked to a change request shows that link, so you can trace a production change back to the review that approved it.

Section titled “Related, lighter-weight screens”

Two related screens live nearby in the sidebar:

  • Chaos Engineering (/gravity/operations/chaos) lets you define and track game-day fault scenarios - target service, fault type (pod kill, CPU stress, latency injection, and similar), intensity, and duration - with a draft → running → completed lifecycle. Fault injection itself is limited to a fleet-enrolled agent, off by default, and excludes network-partition and pod-kill scenario types. Treat most scenario types as something you run and observe yourself, with Sencai recording the exercise and its outcome, rather than something the platform executes end-to-end for you today.
  • UAT Sessions (/gravity/qa/uat) is a lightweight feedback tracker for dogfooding/user- acceptance sessions - star ratings, usability/performance scores, and bugs found per feature area - with an aggregate dashboard. It’s a feedback log, not a formal test-case management tool.

What’s next

Section titled “What’s next”