Learn Semantic Release - Release Monitoring & Post-release Checks

#Introduction

In episode 17 commit messages were disciplined and releases run automatically. But a release is not the end of the work — a release is the start of supervision. A published version isn't necessarily healthy; health must be proven.

This episode covers release monitoring & post-release checks: observability through version tags and dashboards, automatic validation after publishing, and rollback readiness when a version turns out to be problematic.

#Observability: Version Tags & Dashboards

Every release leaves behind artifacts that can be monitored:

• Git Tags — v1.4.0, v1.4.0-rc.2. The tag list is the fastest release chronology; git tag --sort=-v:refname shows the newest versions.
• GitHub Releases — a page containing the changelog, diff, and assets of each version.
• Registry — the versions published on npm or a private registry.
• Dashboard — an aggregation of release data (e.g. BigQuery from webhooks, or a simple dashboard based on the GitHub API) to answer "how many releases this week" and "how many failed".

git tag --sort=-v:refname | head -5
v1.6.2
v1.6.1
v1.6.0

For teams that need automation, GitHub webhooks can send release events to a communication channel or dashboard — with a notification plugin like @semantic-release/slack or a Discord webhook via successCmd from @semantic-release/exec.

#Monitoring Publish Success

A failed publish isn't always obvious. Indicators to monitor:

• The release pipeline's exit code — non-zero means a step failed.
• The version in the registry matches the version the changelog claims.
• The GitHub Release and tag appear — not just a successful npm publish.
• Automatic alerts when the pipeline fails or a version isn't found.

Recommended pattern: separate the "release" job and the "post-release validation" job that run sequentially with needs. If validation fails, the team knows immediately before users report it.

#Post-release Validation Job

The following workflow releases to npm then validates that the version is truly published and the service is healthy:

name: Release
 
on:
  push:
    branches: [main]
 
permissions:
  contents: write
 
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
  post-release-check:
    runs-on: ubuntu-latest
    needs: release
    steps:
      - name: Check the published version in the registry
        run: |
          VERSION=$(curl -s https://registry.npmjs.org/@devnull/learn-semantic-release/latest \
            | jq -r .version)
          echo "Published version: $VERSION"
          test -n "$VERSION"
      - name: Smoke test the production endpoint
        run: |
          curl -sf https://api.example.com/health | jq -e '.status == "ok"'

What happens:

• The release job publishes the new version via semantic-release.
• The post-release-check job waits for the release to finish with needs: release, then fetches the latest version from the registry with curl and validates that it exists.
• The smoke test calls the production health endpoint; if the response isn't a healthy status, the job fails and the team gets an alert from GitHub.

For a stricter scenario, the validation can also download that version's tarball and run a clean-install test (npm install in a fresh container).

#Rollback Readiness

A rollback plan must be decided before an incident, not during one. Some strategies:

• A new version replaces the broken one — apply the fix and let semantic-release bump the version (patch). The simplest and most common.
• Deprecate the version — for npm, npm deprecate paket@versi "mengandung bug" marks the broken version without deleting it.
• Revert the commit — git revert <sha> undoes the change; since a revert produces a revert: commit, semantic-release automatically ships a new version.
• Rollback the deployment — at the infrastructure level, go back to the previous image or tag, e.g. v1.5.0.

Simulate rollback readiness periodically: record the last commit per version, document the steps to deploy the previous version, and make sure every image is tagged with the same version as the release.

#Conclusion

Episode 18 recap:

• Release observability: Git tags, GitHub Releases, the registry, and dashboards.
• A post-release validation job makes sure the version is truly published and the service is healthy.
• Smoke tests and clean-install tests catch failures before users do.
• The best rollback is a new fix version; avoid deleting tags or rewriting release history.
• Prepare and rehearse the rollback procedure before an incident occurs.

With monitoring and rollback readiness, your release pipeline is not only automatic but also trustworthy. In episode 19 we'll open up GitOps and Release Automation — aligning releases with GitOps-based automatic deployment. See you there!