A look back at release engineering

Let’s take a look back at release engineering – my experiences with it, that is. I recently listened to an episode of the AB Testing podcast featuring Katja Obring. (Highly recommended!) Katja mentioned having worked as a release engineer. She, Alan Page and Brent Jensen (hosts of the podcast) discussed the importance of testing specialists having many other skills as well, including release engineering.

As I listened, I realized that release engineering was part of my first job where I did a lot of testing, back in the early ’90s. Starting in the mid-80s, I worked in tech support for a software company. After every new release was sent out, we’d get calls from outraged customers (this was a long time ago, we did all support by phone), saying “How could you not know about this terrible bug!” In self-defense, we support folks asked the developers to let us have the new versions at least a week or so before it went to customers. Then when angry customers called, we could at least say, “We know about that bug, we’ll get a fix to you in a couple of days!”

Hmm, testing!

Our managers looked at this and thought, hmm, testing! Nobody had thought to do it before. “Let’s create a testing and release department!” Naturally, I put my hand up. This is back when software products went out on tapes or floppy disks. Our job was to make sure the new versions didn’t have any showstopper bugs. We did a lot of reading and even went to a testing conference to ramp up our skills.

Then, we got to cut the tapes and burn the disks to send out to customers. We had to verify that these artifacts installed correctly, too. Since we supported mainframes, VAX/VMS, many flavors of Unix, Wang, DOS and OS/2 operating systems, I had a lot to learn!

Learn lots of skills!

Learning system administration skills for all those operating systems is one of the most valuable things I’ve ever done in my career. It was just one aspect of my job, but knowing Unix operating systems in particular opened a lot of doors as I continued my career in the mid-90s. By the early 00s, I was working in a small agile team development at a startup, helping to configure the continuous integration and the deployment pipeline. We started out by not being able to get a releasable artifact at the end of two weeks, and ended successfully practicing continuous delivery.

Collaborating with my developer and sys admin teammates, I learned how to set up and maintain development and test environments. I could deploy build artifacts to dev, test and production environments.  Eventually, we learned to automate all these activities, and moved to a cloud infrastructure.

Early on, my teammates helped me learn how to read log files, monitor production, and help analyze failures. As technology brought us ever-more sophisticated monitoring, observability and analytics tools, we learned to get the most benefit from them.

Collaborate around the whole development loop

Over the past few years, I’ve worked on monitoring and observability teams, and collaborated with platform engineers. I wasn’t afraid of testing activities on the right-hand side of the DevOps and Holistic Testing loops. As I look back on my release engineering roots, I know there’s nothing more stressful than cutting physical tapes! And, I’m extremely motivated to make sure the changes we release don’t inflict pain on our customers.

Build relationships with your site reliability engineers (SREs), platform engineers, and other operations specialists. Whether you specialize in testing or some other software development activity, it’s helpful to know at least a bit about release engineering. You’ll find lots of learning resources for this and other topics related to DevOps, observability and continuous delivery on this resources page.

And if a manager says, “we’re going to do this new thing, who wants to join in?”, put your hand up!