A feature can be finished in code and still be unavailable to anyone who needs it. Delivery closes that gap: it ships a usable artifact to another person or system. The artifact might be a library version, executable binary, container image, or software update. Until it reaches users, their experience cannot guide the next change. section 1.2.4
Delivery is not the same as deployment. Publishing a downloadable binary or library delivers it; making an application run as a service deploys it. A product may need both steps, but a library can be delivered without being deployed. section 4.1
A practical delivery loop keeps the increment small:
- Build and test a small piece of work rather than letting weeks of untested changes accumulate. section 1.2
- Have the pipeline publish the built artifact where others can obtain it. For a release candidate, add automated checks such as load, UI, or smoke tests and any needed manual approval. section 4.1 section 1.2.4
- Observe what happens after delivery. A failed start, poor performance under load, or an unhelpful feature gives the team a different next task. section 1.2.4
Listing 4.1 pipeline.yml
name: CI Checks
on:
push:
branches:
- main
jobs:
test:
....
deliver: #1
name: Release
needs: build
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Download binary #2
uses: actions/download-artifact@v2
with:
name: api
- name: Create Release
id: create_release
uses: actions/create-release@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} #3
with:
tag_name: ${{ github.ref }} #4
release_name: Release ${{ github.ref }} #5
body: |
Still in experimentation phase
draft: true #6
prerelease: true #7
- name: Upload Release Binary
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN:
${{ secrets.GITHUB_TOKEN }}
with:
upload_url:
${{ steps.create_release.outputs.upload_url }} #8
asset_path: api
asset_name: api
asset_content_type: application/octet-stream #9
The pipeline listing makes delivery concrete: a release job depends on the build, downloads its binary artifact, and creates a repository release. section 4.1
Automating publication shortens the wait between writing code and getting it into others’ hands. Delivering smaller increments also reduces work in progress and makes feedback easier to act on. The destination can change—from a repository release to a package or device update—but the pipeline’s basic job remains to turn code into a delivered artifact. section 1.2 section 11.4.3
