What problem does it solve?

Before we begin discussing the mechanics and components of Release Engineering, let’s set the context of its relevance and need.

Release Engineering concerns itself with software that’s digitally or physically shipped to the customers. Given the dominance of cloud technologies, we’ll solely focus on the former—a downloadable artifact.

As discussed in the previous post, Release Engineering solves scaling problems as companies grow from startups to enterprises.

But that only scratches the surface. As we dig deeper, enterprise companies are made up of multiple players each with their own motivations and needs.

Solves Growing Pains

As software businesses grow and hire more engineers, their release process becomes fragile and broken. It becomes hard to coordinate what gets released in which version. This results in the release process being slow. Companies typically use cultural norms like freezing code, performing QA, and maintenance in an attempt to maintain control. It is common to bake in as much time for testing and bug fixes as it takes to develop features.

Even then, the release process is very hard to execute effectively. It’s common to have long working hours as sustainability during these times is a challenge.

Release Engineering aims to solve this problem by centralizing the machinery of releasing around a set of principles and norms in a company. Release Engineering integrates a set of norms and principles into an automated process and a nimble team to go along side it that allows the business to initiate the release process at any point in time.

It enables the business to be confident in releasing their software repeatably and reliably. And as the business grows with more and more customers, a robust Release Engineering system makes sure the company continues to meet its increasing demands satisfactorily.

So, what did we ship?

Software today is a snapshot of a complicated combination of libraries. When companies ship their software to customers, not knowing what they shipped creates a variety of problems that makes it embarrassingly confusing and difficult to determine whether they need a bug fix.

Legal and compliance requirements at any reasonably serious enterprise also make it necessary to keep an inventory of what they are releasing to their customers.

Generally, this has been solved by assigning a global identifier version (e.g. 1.0.0 so on) to each artifact that’s bundled together. But this breaks down when it isn’t clear what that version is made up of, or requires painful traversing to determine each component’s version number. And let’s not bring up spreadsheets, please.

Releasing a version of the product by merely creating a zip file from a folder of various components and assigning it a unique version is at its best lazy and at its worst plain dangerous.

A solid Release Engineering system takes its lessons from Supply Chain Management to make sure each included artifact is traceable to its equivalent of the atomic unit. The version of the released software simply acts as a pointer to a set of all these component versions in a topology that make it a snap to determine what actually was indeed shipped to customers.

Knowing this information means that companies release a fix or address a security vulnerability confidently and efficiently.

Addressing Security Vulnerabilities

A shipped piece of software to its customers is used in a variety of contexts. The product that inspired this book, Tanzu Application Service, is used by governments, banks, e-commerce companies, and other various high-demand and crucial services.

This means that security vulnerabilities across its fifty components and thousands of libraries threaten customers and their users.

An efficient automated release engineering system allows the company to:

• Minimize as much time as possible in compiling the release artifact to be shipped to customers.
• Confidently ship the fix without introducing any unknown functional or performance regressions.

Did I break the system?

As discussed, companies attempting to grow by hiring more engineers do not want to ship fewer features. And yet, that is exactly what typically unfolds. At a certain point, adding more engineers to the company lowers the speed of development in a shared codebase. Solving through software architecture and org design is a must and a topic worth researching.

But one factor that leads to slow release cycles tends to be the dependence of one component’s work over another. On top of that, this interdependence means that a single customer outcome requires touchpoints across different codebases and teams. It frustrates both the business and the engineers alike.

Release Engineering here aims to provide a service that relieves the developer from the responsibilities of building and compiling a piece of software at any point in time. And precisely because of that, a built binary with a new feature allows the developer to test their work easily. Apart from providing fast feedback loops, it also allows the developers to keep working relatively independently from others.

The hallmark of a good release engineering system also lies in providing testing environments and automated test suite runners so developers continue to focus on doing good work.