aureliasrs specifications
Lifecycle specification

Release Pipeline

Every change moves through the same Build → Test → Publish pipeline locally, on the pull request, and on merge, ending in a deployment only where there is one.

Applies at
docs/RELEASING.md
Status
Stable
Source · managed
docs/RELEASING.md

01 Defines

The path a change takes from a developer’s machine to production: one Build → Test → Publish pipeline, repeated at each stage, with validation shifted as far left as practical.

02 Applies when

  • A repository produces artifacts, infrastructure, or a deployable site.
  • Changes reach the main branch through pull requests.
  • Pull request results need to predict what merge will do.

03 Boundaries

  • Deployment applies only where the repository has something to deploy; for some repositories publishing the artifact is the release.
  • The pipeline describes stages, not tooling; the work in each stage is done by repository commands.

Expected behaviour

  1. 01
    The local build exercises the same logic CI/CD runs, and local failures are fixed before a pull request is raised.
  2. 02
    The pull request pipeline validates as much of the release as possible and publishes CI, edge, or staging artifacts.
  3. 03
    Infrastructure under env/ is validated as part of the pull request pipeline.
  4. 04
    Merge runs the mainline pipeline, which publishes production artifacts and, where applicable, deploys them.

Behaviour#

The same three stages run at every point a change passes through. What changes from stage to stage is only where the output is published: nowhere locally, to an edge or staging location on a pull request, and to production on merge.

FlowOne pipeline, every stage
  1. 01 Build Produce the artifact or site from source
  2. 02 Test Exercise it with the same logic CI runs
  3. 03 Publish Push the output to the location this stage targets

Running that pipeline three times is the point. A pull request that already built, tested, and published to an edge location has rehearsed most of the release, so merge is a promotion rather than a first attempt.

Stages of a change#

LifecycleFrom local change to production
  1. before a pull request Develop locally Build and test with the commands CI also runs
  2. on every push to the branch Pull request Build, test, and publish edge or staging artifacts; validate env/
  3. once Review and merge A person reviews the result the pipeline already produced
  4. on merge Mainline Build, test, and publish production artifacts
  5. if applicable Deploy Continue the published output into a production deployment
  • Review feedbackDevelop locally

Shift left#

The pull request is where validation is cheapest and most useful. Anything the mainline pipeline will check — the build, the tests, infrastructure validation, artifact publication — should already have been exercised on the pull request, so that merge introduces as little new behaviour as possible.

Pull request pipeline

  • Build and test the change
  • Publish to edge or staging
  • Validate infrastructure roots under env/

Mainline pipeline

  • Build and test the merged result
  • Publish production artifacts
  • Deploy to production, if applicable

Examples#

In this repository the final stage is real: the published output is a Hugo site, and deploying it is the five-step make deploy described in Static Site Delivery . Locally, the pre-pull-request half of the pipeline is:

make check.hugo    # Build the site into public/
make lint          # Every installed linter
make validate      # Build, then Terraform validation and link checking

Connections

How Release Pipeline relates to the library

Release Pipeline and 2 related specificationsStatic Site DeliveryStatic Site DeliveryWorkflowsWorkflows
RefinesComposesRelies onFollowed byContrasts with

Composes

Relies on