Release Engineering is how software gets packaged, shipped, and distributed to the end users.


“Adapt what is useful, reject what is useless, and add what is specifically your own.” - Bruce Lee

Over the past four years, I’ve worked on a team that's responsible to ship Tanzu Application Service. It's a flagship product of the Tanzu portfolio from VMware that allows customers to deploy their workloads with a single command.

We ship new versions of our product a lot of times each year. The figurative conveyer belt never stops as upstream teams continuously push new changes to the product while my team focuses on shipping reliable releases to the customers.

Releasing a product in our team at a quarterly cadence used to be stressful. Experienced team members seemingly knew how the process worked and therefore, were equipped to keep the workflow going while new team members felt lost. Not only was the process lengthy, ridden with tribal knowledge with a large number of steps to follow, it also required 6-9 months of pair programming to get up to speed. Problems seemed tricky to discover and even trickier to solve.

Fast forward to now. The release process is fluid. People don’t feel pressured to work after-hours. The system brings problems to the forefront in a logical manner, and where it lacks, our practices ensure that no inefficiency is ignored. The system improves over time, prioritizing human needs over machinery.

Inspired by the principles laid out by Site Reliability Engineering, we experimented and developed a set of principles, tools, and tactics to bring methodical improvement to the release process. We prioritized not only the engineering process and the tools involved but the psychological toll of working on a less-than-fun project.

This journey of continuous improvement is by no means over but we've drastically improved what it means to engineer releases and ship the product efficiently. This website brings forth the underlying theory, principles, and practices of Release Engineering that I have learned and found valuable.

I knew that other software companies had deep Release Engineering practices but I couldn't find anything particularly useful. Most of the literature is also stuck in the age of CDs and physical media. I learned it through my co-workers, experimentation, and a lot of inspiration from peer disciplines such as Site Reliability Engineering, DevOps, and Continuous Delivery.

I am writing this with hopes to help someone who may be in the same shoes I once was.

Subscribe to The Release Engineer

Sign up now to get access to the library of members-only issues.
Jamie Larson