DevOpsPadDownload

Release a new image to a Deployment

Choose an artifact under 制品库 (Artifacts) and click 发布 (Release). Pick an existing Deployment and container, then click 生成发布计划 (Generate release plan). DevOpsPad reads the current state, runs a Kubernetes server-side dry-run and shows the 当前镜像 (current image) next to the 目标镜像 (target image). Click 确认发布 (Confirm release) to apply it; DevOpsPad then waits until the rollout is ready, for up to 180 seconds.

Only one container image changes. Replicas, other containers and the rest of the Pod template stay as they are. Every step is written to a release record in your project.

The release plan dialog (确认发布计划) showing the Deployment, container, current image digest and target image digest, with the confirm button (确认发布)

Steps

  1. Select the environment and application in the Infra sidebar.
  2. In 制品库, find the version you want and click 发布. If the list is empty, register an artifact first.
  3. In the 发布制品 (Release artifact) dialog, choose the Deployment and the 容器 (Container).
  4. Click 生成发布计划. The dialog changes to 确认发布计划 (Confirm release plan) and shows both image references and the plan’s expiry time.
  5. Check the environment, namespace, Deployment, container and both digests. Use 返回修改 (Back to edit) to change anything.
  6. Click 确认发布. The dialog shows “正在执行发布并等待就绪…” (releasing and waiting for ready) until the rollout finishes or fails.
  7. Open 制品发布 (Releases) to see the record and its steps.

What happens under the hood

When you generate the plan, DevOpsPad reads the Deployment and binds the plan to the application’s selector, the namespace, the Deployment UID and resourceVersion, the container, the image digest and the cluster endpoint it read from. It then sends the change as a server-side dry-run, so admission errors surface before anything is written. The plan is kept only in memory, expires after 10 minutes and can be used once.

When you confirm, DevOpsPad:

  1. Acquires a coordination.k8s.io/v1 Lease in the target namespace, named after the Deployment. The lease is held for 300 seconds and the whole operation must finish within 180 seconds. A second DevOpsPad user releasing the same Deployment is blocked until the lease is released or expires.
  2. Re-checks the Deployment’s UID and resourceVersion. If someone changed or replaced it since the plan, the release stops.
  3. Updates the container image and adds a devopspad.io/release annotation to the Pod template.
  4. Waits until the controller has observed the new generation and the updated, available and total replica counts match the desired count.
  5. Writes each step to releases/<uuid>.json. If writing the record fails, execution stops.

Results

Status Meaning
发布完成 (Release complete) The rollout reached the desired state
发布未完成 (Release incomplete) Timeout, connection loss or a concurrent change. Check the cluster’s real state
执行中 / 待核实 (Running / needs verification) The client stopped mid-release, for example after a crash. Verify before retrying

DevOpsPad never retries or rolls back on its own. If a release is incomplete, refresh the Deployment page and decide what to do. Retrying blindly after an interrupted client is discouraged (“如客户端曾中断，请刷新集群核实状态，不要直接重试”).

Limits

  • Only existing Deployments. StatefulSets and DaemonSets can be viewed but not released to. Creating or deleting workloads is not supported.
  • One container per release.
  • Other tools (kubectl, CI, GitOps controllers) do not respect DevOpsPad’s Lease. The resourceVersion check still protects against overwriting their changes between plan and apply.
  • Clients must have reasonably synchronized clocks, because the lease uses timestamps.
  • If a GitOps controller manages the Deployment, it may revert the image.

Permissions

The identity in the connection needs get, list and update on deployments in apps/v1, and get, create and update on leases in coordination.k8s.io. See RBAC permissions.

Frequently asked questions

Does DevOpsPad roll back automatically if a release fails?

No. A failed or timed-out release is recorded as incomplete and you are asked to check the cluster. You can then start a rollback yourself from a previous successful release.

How long is a release plan valid?

Ten minutes, and it can be executed only once. After that, generate a new plan so it reflects the cluster's current state.