Packages, Releases, and Deployments

Each service has separate Packages, Releases, and Deployments views. The separation makes it possible to prove which source was built, which artifact was approved, and where it was activated.

Packages

A package records a build from source. Open it to review the branch, commit, build status, duration, logs, generated artifact, and any AI code-review result. A successful package can be used to create a release.

If the build fails, fix the source or build configuration and trigger a new package; do not try to repair an immutable historical artifact.

Releases

A release is a named selection of a successful package. The release page links back to its package and lists every deployment created from it. Use Deploy to environment to activate the release in the next eligible environment.

Creating another release from the same package does not rebuild the code.

Deployments

A deployment records the activation of one release in one environment. Open it to inspect current status, timing, pipeline stages, pre-deploy work, runtime rollout, logs, and webhook result when configured.

If a deployment is still running, wait for the current stage or cancel only when the UI offers that action and the consequences are understood. For a failure, identify whether it occurred in the pre-deploy command, artifact deployment, health verification, or finalisation stage.

Audit Questions

For any production change, you should be able to answer:

1. Which repository commit created the package?
2. Which package created the release?
3. Who deployed the release, when, and to which environment?
4. Did health checks and uptime remain healthy after deployment?
5. Which earlier release is the rollback candidate?

See Trigger a Package Build, Deploy a Release, and Roll Back.