Skip to content

feat: per-deployable tracking (ship the existing plan) #22

Description

@joshua-temple

Problem

There is a per-deployable state tracking plan that hasn't shipped. Today the framework tracks one deploy SHA per env per callback — fine for monolithic deploys, less so for callbacks that render N services into a single deploy step (where per-service version visibility matters for rollback awareness).

Proposed

Land the plan: track per-service version (or per-sub-artifact) within a single deploy callback's state, enabling per-service rollback awareness without bypassing framework state.

Scope:

  • Per-sub-artifact tags inside state.<env>.deploys.<name> (e.g., services: {svc-a: v1.2.0, svc-b: v1.2.0-rc.3})
  • Promote/cascade preserves per-sub-artifact values across envs
  • Optional: emit a query (cascade state get --env <env> --service <name>) for rollback workflows

Impact

Improves rollback awareness for multi-service deploys (e.g., kustomize-based deploys with N services rendered in one callback). Not strictly blocking monolithic-deploy pilots but valuable for GitOps mirrors and any deploy that fans out into sub-units.

The rollback command issue depends on this — once per-deployable tracking lands, rollback can scope to a single sub-artifact.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions