III. Autonomous Delivery

The Requirement

Build, test, and deployment logic must be versioned within the application.

The Problem

CI/CD pipelines are often treated as external infrastructure, hidden away on a Jenkins server or managed by a separate platform team. When the build system changes, historical versions become unreproducible. Version 1.0 of your application is effectively lost forever.

In a GitOps model, the problem persists in different form. Your Application.yaml, health checks, and rollback strategies are still delivery logic. If you lose that configuration, you lose the ability to deliver consistent service.

The Practice

A hermetic asset contains its own delivery instructions:

• Pipeline definitions (.github/workflows, .gitlab-ci.yml, Jenkinsfile) in the repository
• Build scripts that produce deterministic outputs
• Deployment manifests specifying exactly how The Asset reaches production
• Rollback and recovery procedures encoded

If you extend shared pipeline templates, pin them to immutable versions. The template itself is an asset that must be delivered with all five pillars.

The Testing Pyramid

Tests are how The Asset validates itself:

• Unit tests validate Layer I (logic in isolation)
• Integration tests validate Layer I + II (logic with mocked context)
• End-to-end tests validate Layer I + II + III (the full asset in motion)

The definition of done is not deployment. It is deployment plus self-verification. Without tests, The Asset relies on external validation to justify its existence.

The Litmus Test

If your build server was replaced tomorrow, could you redeploy any historical version using only what exists in the repository? If the answer is no, your delivery logic is not autonomous.

What This Enables

The Asset becomes self-delivering. No external system holds implicit knowledge about how to build or deploy it. Any engineer with repository access can understand and execute the full delivery process.