A release turns a built product into something other people can easily consume. It may be a downloadable binary for QA, developers, or customers, and it can happen before the product is deployed as a running service. section 4.1
A practical release workflow separates delivery from deployment:
- Build the product and attach its binary to the delivery pipeline. section 4.1
- Publish the artifact as a repository release that recipients can find and download. section 4.1
- Let QA or other users test it while development continues, then release after the system behaves as planned. section 8.3.2
- Use the resulting feedback to decide what to improve instead of waiting for a perfect first version. section 4.1
A pipeline release
A CI workflow runs on pushes to main, waits for the build, downloads the api binary, and creates a repository release tagged from the Git reference. The release page gives the team both release information and an artifact to test. section 4.1
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
Inspect the pipeline configuration to see how testing, build dependencies, artifact download, release creation, authentication, and tags fit together. section 4.1
Stable releases also make communication important: teams need to know which software version they are testing or releasing. Continuous deployment can deliver minor fixes while testing proceeds, but a deliberate release marks the version considered ready. section 8.3.2
