Better Blueprint Draft/Publish Workflow — Allow Testing Before Publish & Maintain Stable Blueprint Identity

Problem Statement:

• When creating a blueprint, teams often want to test creation of stacks before the blueprint is considered ready for production.

• Currently, blueprints in “Draft” state are not usable for creating stacks (per documentation: stacks can only be created from a published blueprint).

• Because of that, users must publish the blueprint to test it → but once published, the blueprint is immutable, and updating it requires cloning → resulting in a new blueprint ID.

• If downstream systems or automation refer to the blueprint ID, cloning breaks those references and causes friction (especially during onboarding and experimentation).

• Some teams workaround by deleting the published blueprint and re‑publishing, which is unsafe, cumbersome, and error‑prone.

• Result: onboarding/experimentation is slower, error‑prone, and user frustration rises.

Use Cases / Impact:

• A platform team wants to iterate on a blueprint (e.g., for a new service): test stack creation, test variables, labels, contexts. They don’t want every iteration to break their automation or require new IDs.

• When many stacks use the blueprint for production, having a stable blueprint identity makes tracking, integration, and governance simpler.

• For CI/CD or GitOps setups, referencing blueprint IDs (or metadata derived from them) is much easier if the ID remains stable across versions.

Proposed Solutions:

1. Allow “Test publish” mode — A special publish flag that makes the blueprint usable to create stacks, marked as “test” or “pre‑production”, not locked yet; once validated, convert it to full publish.

2. Allow editing of published blueprint (or overlay edits) — Instead of requiring clone → new ID, allow changes to an existing published blueprint (or maintain an overlay version) and preserve the blueprint identity.

3. Stable/overrideable Blueprint ID — When cloning or versioning, allow users to specify the ID (or alias) so automation doesn’t break when referencing it.

4. Branch/versioning UI inside blueprints — Visualize “published v1”, “draft v2” inside same blueprint identity, so users can test without creating a new ID or deleting the old one.

5. Clear flag/metadata for test vs production stacks created from a blueprint — So users can safely create “throwaway” stacks from a blueprint (without affecting production workflows) and then flip to production mode.
   

Why this aligns with Spacelift goals:

• Improves self‑service speed for non‑infrastructure teams (one of the goals of Blueprints)

• Reduces user friction and time‑to‑value for new teams onboarding with Blueprints.

• Maintains governance and auditability: if needed the system can log version changes, but doesn’t force disruptive ID churn.

• Supports the “experiment, then rollout” workflow – major expectation for blueprint‑driven self‑service.