Empowering Releases

How we empowered anybody on our team to release with confidence.

Published March 31, 2023

#agile-in-practice#process-improvement#releases
empowering-releases

Issue

As the Nuve team became more comfortable releasing features in pieces, managing scope creep, and testing effectively as we went; our development pace and quality increased significantly. This meant that more developers were adding new productive changes to the codebase for every release.

This led to a subtle shift: almost every release included changes from multiple developers, even though we were still releasing one or two times per week. This meant that each release involved changes that were made by someone other than the person who was releasing the code.

Don’t get us wrong, this is a great problem to have, but we still needed a way to provide the person who was leading the release with a sense of comfort that they would release all changes without issue.

Solution

There were two questions that we needed to address:

  1. Who runs the release when multiple people have made changes?
  2. How does that person release with confidence?

Our solutions were simple and low tech.

Question 1: Who Runs the Release

The person who made the highest risk change within the release runs the release.

Generally this is the person who made the most changes, but not always. For example, if a person changed a whole bunch of marketing copy, they probably changed a lot of code. But those changes are very low risk to the to the release process. Changing text is no big deal.

Whereas if somebody changed a whole bunch of user data as a part of a release, that might involve very little code but could be very high risk. So that part of the release would have to run smoothly and the person who added those changes should run it.

Question 2: How Do They Release With Confidence?

Each developer needs to write release notes for changes that must happen outside of the normal release process.

A “normal” release process will vary team to team, but ours was essentially as follows . . .

First, release the code that runs on our servers:

  • Change the back end code
  • Run routine database updates
  • Restart to ensure changes take effect

Second, release the code that runs in the browser:

  • Change the front end code
  • Restart to ensure changes take effect

So that was our starting point. If the release required anything outside of that process, say running a script or installing something new, that had to be added to the release notes. And it had to be added in a foolproof manner. Something like this:

# Release Notes

#######################
# Server Side Release
#######################
# After pulling code and making routine database updates, run
python3 .../scripts/post_release_script.py

#######################
# Browser Code Release
#######################
# After pulling code, before be sure to run
make build

These aren’t actual release notes, but they should get the point across. There should be literally zero judgment calls during the release process.

The best possible process is foolproof. Like, copy/paste this line and press enter, then copy/paste that line and press enter.

Results

This process led to peace of mind for the developer who ran the release. They could trust that they had all the steps to run the release documented clearly.

Though we used to have minor issues with releases in our early days as a team (”Oh no! I forgot to XYZ so something is broken. I’ll go fix that!”). We haven’t had an issue across dozens of releases after implementing this process.

Want to code like the top 1% of elite SAP developers?

Elevate your skills with exclusive insights, expert tips, and cutting-edge best practices. Don't miss out – become part of the elite SAP community today!

Related Posts

agile-where-we-started

Agile: Where We Started

Nuve started with a bare-bones agile development setup. This post walks through the basic elements and why each was included.

#agile-in-practice#agile-journey#rapid-development
isolated-development-environments

Why Isolated Development Environments?

How isolated development environments enabled fast, high quality development with good economics.

#agile-in-practice#devops
git-version-control

Git Version Control

How and why we started using Git at the very beginning of our journey with the tool.

#agile-in-practice#devops
release-quality-issues

Solving Release Quality Issues

A QA environment and git workflow improved our production releases, establishing confidence and minimizing risks and bugs.

#agile-in-practice#git-workflow#testing
hotfixes

Peace of Mind with Hotfixes

Adding a hotfix workflow to our toolkit inspried confidence in both our development workflow as well as our release procedures.

#agile-in-practice#devops
release-in-chunks

Release Big Stuff in Chunks

A big project stalled and we re-started it by splitting it up into smaller pieces.

#agile-in-practice#releases#small-prs
scope-creep

Dealing With Scope Creep

How we learned to recognize scope creep and manage it.

#agile-in-practice#project-management#scope-creep