Embracing the ‘Boring’ in Software Releases

In the fast-paced, often adrenaline-fueled world of software development, the release of a new version has long been treated as a monumental event.

Picture the scene: last-minute code freezes, tense planning meetings, a flurry of bug fixes, and the nail-biting decision of whether this is a minor tweak or a game-changing 2.0.

But what if, instead of this drama, the entire process was, well, boring?

This is the provocative vision put forth by Patrick Lee Scott, a seasoned software consultant and DevOps expert, who argues that the ideal software release should be nothing short of transparent, effortless, reliable, and informative.

Far from diminishing its importance, Scott believes that stripping away the ceremony transforms releases into a predictable, professional, and ultimately more trustworthy aspect of a project’s lifecycle.

Scott’s philosophy isn’t born of a desire to stifle innovation, but rather to streamline the mundane.

His journey, he explains, began in the early days of his career when releases were indeed high-stakes affairs.

The entire team would rally around milestones, meticulously planned through sprints, tasks estimated with Fibonacci numbers or T-shirt sizes, and a collective holding of breath as the “deliverable of deliverables” was finally shipped.

The version number itself was often a subject of passionate debate, sometimes even dictated by marketing whims, rather than a clear reflection of technical changes.

This emotional roller coaster, Scott realized, was unsustainable and inefficient.

His perspective began to shift when he delved into open-source contributions, particularly npm modules in the Node.js ecosystem.

It was here that he encountered ‘semantic-release’, a library that championed a principle of separation of concerns based on semantics.

The core idea was elegantly simple: structure commit messages in a specific way – known as Conventional Commits – and let automation determine the version bump.

A ‘BREAKING CHANGE:’ in the commit body would trigger a major version increase, a ‘feat:’ a minor one, and a ‘fix:’ a patch.

This approach, Scott notes, removed the human element, making releases robotic, objective, and inherently communicative.

A jump from v2 to v3 immediately signaled a breaking change, while v2.0.0 to v2.1.0 indicated a new feature.

This system also neatly generated changelogs, turning a potentially tedious task into an automatic byproduct of good commit hygiene.

While semantic-release proved transformative for Node.js projects, Scott’s evolution into a DevOps consultant working with scalable distributed systems exposed its limitations.

His new challenge involved deploying applications, services, databases, and queues across multiple languages and frameworks, a landscape where a Node.js-specific tool felt like a hacky workaround.

The monolithic pipelines common in the Jenkins era, where a single, sprawling script handled everything from quality checks to deployment, also presented a recurring headache.

Scott yearned for the simplicity of semantic versioning but needed a language-agnostic, modular solution.

His answer, after years of trying to piece together disparate open-source components, is a new tool named ‘vnext.’

Written in Rust for speed and efficiency, vnext is a CLI tool designed to compute the next semantic version based purely on a project’s Git history.

Its genius lies in its universality; it doesn’t care if you’re working with Rust, Python, Go, or Node.js.

The process of getting a new version, updating files, generating a changelog, tagging, and pushing remains fundamentally the same.

Scott’s approach breaks down the release pipeline into two distinct, modular phases, primarily leveraging GitHub Actions:

1. On commit to the trunk branch, version, and tag:

When a commit lands on ‘main’ or ‘master,’ quality checks run.

If successful, vnext calculates the new version number, updates it in the codebase, generates a changelog, and pushes a Git tag.

2. When a tag is created, build new versions and release them:

This step is triggered by the tag from the first pipeline.

With the version already bumped and the changelog generated, it focuses solely on building and releasing artifacts using the new tag as the base.

This separation of concerns is critical.

Versioning is about commit history and semantics, while releasing is about building and distributing artifacts.

By decoupling them, Scott achieves greater modularity and reusability.

He offers shared GitHub Actions workflows that act as “LEGO blocks,” allowing developers to easily copy and paste configurations tailored to their project type – be it a Rust binary, a Dockerized application, or a Helm chart for GitOps deployment.

A practical nuance Scott addresses is the behavior of GitHub Actions tokens.

By default, these tokens can’t trigger subsequent pipelines, a deliberate safeguard.

To overcome this, Scott provides methods using Deploy Keys or Personal Access Tokens (PATs), with vnext even offering a command to generate deploy keys for repositories.

This ensures the automated flow remains unbroken without compromising security.

The often-overlooked changelog also receives its due.

Generated automatically by vnext from the Conventional Commits, the CHANGELOG.md file becomes the body of the GitHub Release, communicating project changes clearly and consistently to users.

This transparency, Scott emphasizes, builds trust and helps developers adopt new changes with confidence.

He even advocates for GitHub’s “Squash and Merge” feature for Pull Requests, allowing for a clean, descriptive final commit message that directly feeds into the changelog.

In essence, Patrick Lee Scott is demystifying and de-dramatizing a core aspect of software development.

His work with vnext and modular workflows isn’t about making releases less significant, but about making them less taxing.

By embracing automation, semantic versioning, and a disciplined approach to pipelines, Scott empowers teams to achieve “boring” releases – a state where the process is so smooth, predictable, and informative, that it simply fades into the background, allowing developers to focus on what truly excites them: building great software.

In an industry often plagued by release anxiety, a bit of boredom might just be the most revolutionary idea of all.