Lab: Branches, Builds and Deployments📋

Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.

The Lab lifecycle must make source selection, provisioning, build progress and active execution observable. Operations run through registered Bundles, binary wrappers and provider adapters.

Managed branch events📋

A branch created through the Lab, or observed in a configured remote repository, can create a version track under the site's policy. The event must identify the repository, branch and observed revision.

The Lab allocates or reuses the track's workspace, instance, data scope and domain binding. Repeated delivery of the event must not create duplicate managed instances. Branch names need deterministic hostname-safe allocation with collision handling; the original branch name remains available in metadata.

DNS and routing are provider operations. A configured wildcard may already resolve the new hostname. Readiness still requires the intended route, certificate where applicable, application and dependencies.

Candidate lifecycle📋

The lifecycle must report which inputs each candidate used. If a newer branch update arrives during a build, completion of the older build cannot silently replace the desired newer candidate. Activation must verify its expected target state.

Execution backends📋

Docker/Podman adapters supply local engine capabilities. Compose and Kubernetes adapters supply deployment capabilities. The plan must identify the actual provider combination, required binaries, volumes and network/service dependencies.

Commands execute through typed wrappers with structured argument tokens, exit status, diagnostics, cancellation and secret redaction. The Lab tracks provider resource identifiers so retries and cleanup address the intended resources.

Readiness is specific to a surface: frontend routes, admin startup and required operations may need different probes. A passing container status alone is insufficient.

Updates, stopping and cleanup📋

Stopping a branch preview, retiring its binding, deleting a workspace and deleting its data are separate operations. Merge or branch-deletion events invoke configured retention behavior. They do not silently erase retained work or business data.

Each operation records its stage and outcome. Partial failure must leave enough information to retry, reconcile or recover without duplicating resources.

A shared Lab can manage many instances. Its public exposure remains configurable; the integrated capability is not removed simply because the management UI has no public route.

Managing the Lab itself📋

The initial host loads a packaged capability set and Lab description before depending on its managed GitLab or package feed. Self-updates identify the management components that may restart and preserve a recoverable operation record.

Desired state and observations must stay distinct. A saved Lab model is not reported as applied until execution and observation establish the corresponding state.

Acceptance📋

LAB-01: managed branch creation allocates one instance and usable binding; repeated events reuse it.

LAB-02: failed or superseded builds cannot silently become the active release.

LAB-03: stopping a preview follows retention policy and preserves data unless a separate authorized deletion requests otherwise.

LAB-04: the seed host loads before managed services exist and can observe a subsequent self-management change.

GitLab's review-app lifecycle↗ (ouvre dans une nouvelle fenêtre) is an integration reference, not evidence that the Diem lifecycle is implemented.

Previous: Admin Modules and Pluggable Types · Next: Workspaces, IDEs and Hot Reload · Series index · Section index