Why Release Engineering?

Photo by Shane Aldendorff on Unsplash

Beyond the realm of the programmer hobbyist lies customer focused software development, and scale — serving more users. In this new realm, questions arise like: How quickly and easily can you share an app demo with stakeholders? How quickly and easily can you resolve production issues by releasing a fix to production? Which begs the next question, how long does it take to release the app into production after making only a one-line code change?

We often try to answer these questions long after we write our application. This is way too late for the serious software product developer. From the beginning to the end of each product development cycle or iteration your eyes should be on the customer, first internal and then external.

As the fourth value from the manifesto for agile software development states, responding to change over following a plan is important; and might I add responding quickly is paramount. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (https://agilemanifesto.org/principles.html)

Try seeing your application from the end-user’s point of view. Simply putting it, your application is comprised of executable code, a specific configuration, a host environment, and data. Since our focus is on mobile app release engineering and the mobile app CI/CD pipeline, we pay more attention to the executable code, the app configuration, and its host environment; the host environment in this context would be the physical mobile device the executable code runs on. The data coming from the backend API, although important, is beyond the scope of the mobile release engineering pipeline.

If there is a change in any of these four components the application has essentially changed, and every change needs to be verified. And not only does every change need to be verified, but changes in the application need to be released to the app user quickly.

Why all the emphasis on speed and quickness you ask.

“Speed is essential because there is an opportunity cost associated with not delivering software.” p11 Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation by Jez Humble & David Farley

So the release velocity metric is an important one. As your app grows in complexity so can your release process. Release can become painful and very time consuming, especially when the CI/CD pipeline is neglected or practically non-existent; this is similar to having a waterfall development approach to designing and building a CI/CD pipeline. The underlying fundamental process of releasing is to first build or compile the application, test it, package the build artifact and then release it.

Here’s a common CI/CD pipeline process including the very important test regime:

• Application must be compiled and built. Build should be hermetic, that is, builds should be consistent and repeatable. They are insensitive to the software installed on the build machine.
• Unit and integration tests must pass
• A certain level of test coverage and other relevant metrics must be met before moving forward. Static code analysis is often used to measure the application code quality
• Functional acceptance tests must pass (for example, user interface and end-to-end tests)
• Non-functional test must pass — for example, performance and security testing
• Distribute application binary for exploratory testing or employee-based beta testing
• Distribute application for release to the customers

Automation plays a critical role here. Anything considered toil should be automated. And by toil I mean those manual, repetitive, automatable tasks that are a part of the workflow. Since toil comes in various forms, when considering the elimination of toil, other criteria are considered like the toil being:

1. Reactive rather than strategic or proactive. An example could be having to handle instant message or email alerts. This toil is interrupt-driven and can be distracting and disruptive, taking away focus from higher-value tasks.
2. Void of enduring value (i.e. no permanent improvement is gained from repeating the task several times)
3. Scalable (does task load or complexity grow linearly or faster with the growth of the project). If the automated toil is still relevant as the project grows, then it was worth automating. It was scalable.

When considering the people devoted to releasing software quickly and efficiently, here’s what Dinah McNutt says in Release Engineering: How Google Builds and Delivers Software,

“Release engineering is a specific job function at Google. Release engineers work with software engineers (SWEs) in product development and SREs to define all the steps required to release software — from how the software is stored in the source code repository, to build rules for compilation, to how testing, packaging, and deployment are conducted.”

Release engineering considers the three pillars or principles of DevOps, but it’s not accurate to think of it as just DevOps even though the roles and responsibilities in each domain often overlap. DevOps does not include version control and source control management, build automation and test automation, nor does DevOps focus on building tools to increase developer productivity and increase the speed of software delivery and deployment. DevOps has a larger scope as explain here, where as release engineering focuses on a continuous integration and deployment pipeline with an input of developer source code and an output of a signed binary product that’s ready for release.