Browse and search documentation
Application releases and changes
Register a service, configure build and deployment environments, follow release steps and use a verified rollback path when needed.
On this page
Prepare for a release
- First open Releases and changes → Release environment to check orchestration, controlled jobs, the dedicated build pool and artifact delivery. A ready base environment does not replace service-specific target, permission and pre-release checks. Have an administrator resolve any missing prerequisites.
- Register the service under its application in CMDB, then bind it in Releases and changes. Resolve any legacy configuration marked as awaiting asset association first.
- Prepare a dedicated build pool, online Agents and artifact storage. Select build and deployment nodes separately rather than using production hosts as default builders.
- Confirm target runtimes and networking. Host deployment does not install runtimes such as Java for you. A cluster administrator must configure imagePullSecret for private Kubernetes images.
Configure the service
- Repository: enter the Git address and default branch. Use managed credentials matching the repository protocol, preferably dedicated credentials with only required repository access.
- Build: set the command, exact artifact path and available build environment. Container and host builds differ; fix missing prerequisites instead of expecting an automatic fallback.
- Deployment: configure systemd hosts, single-host Docker or Kubernetes for each environment. Select exact hosts for host modes and a cluster plus namespace for Kubernetes.
- Observation: select health checks and observation metrics. Test Prometheus connectivity and queries first. Waiting for a fixed duration alone is not a business-health check.
Trigger and track a release
- For the first run, create a release manually and verify service, environment, branch or tag and target scope.
- Follow enabled change-ticket, release-window, freeze and approval policies. Inspect unmet conditions rather than retrying to bypass them.
- Follow environment checks, checkout, build, artifact return, deployment, observation and recording. Inspect the state, summary and output of any failed step.
- After completion, verify the target service, artifact and observation result. A successful build does not mean the release completed.
Pause resume and rollback
Pausing stops later steps from advancing but does not forcibly terminate the already dispatched step. Review current targets and step state before resuming. Terminal runs are not handled as active ones.
Rollback requires an available historical artifact, matching deployment configuration and permissions. Application rollback does not automatically undo database changes; assess data compatibility and recovery separately before releasing.
Investigate release failures
| Stage | Check first |
|---|---|
| Environment checks | Agent, runtime, disk, directory access and ports |
| Checkout | Address, branch and protocol/credential match |
| Build or artifact return | Failure output, toolchain and exact artifact path |
| Deployment and observation | Target environment, image pulls, health checks, metric thresholds and no-data policy |
Something differs from your environment?
Send your deployment version, page and a redacted description so we can investigate and update the guide.
weiwendi@aiops.red