#12 Ephemeral Test Environments and the Winds of Change

<< Previous Edition: The Rise of 10X SRE

“A ship is safe in harbor, but that’s not what ships are for.”

— William G.T. Shedd

When I entered the software industry, the first term I found surprising and amusing was "shipping software." The metaphor of ships has not remained limited to shipping. Containers and containerized applications are a category in themselves with everything which goes along with it like docker, harbor, and whatever else imagination permits.

If you look at software release stages in the most simplified way, they can be divided into three stages:

1. Development
2. Production
3. Everything in between

The first two are very deterministic. We need to write software before it can be run. We need to run software for it to be useful. Everything in between is needed because we live in an imperfect world.

Continuous Integration & "code first" thinking

Humans are creatures of habit, and they stick on to whatever they are comfortable with, even if it has become irrelevant. Continuous integration is a perfect example of that. While CI was a good approach in the "code first" era, in the "service first" era, CI can only be justified with baling wire and duct tape, and I see ample application of both.

If we unpack three stages of the DevOps pipeline, they are: build, test and deploy. You write software, and you test it. You compile software, and you test it. You package software you test it. You ship software and hope you do not have to test it (in production).

The problem with the build, test, deploy mindset is that it makes the most important aspect of DevOps a second-class citizen and that is a change. The classic CI thinking looks at the change in the form of commits. The right way to look at a change is in the form of a feature.

Features, Pull Request & "behavior first" thinking

There are multiple ways to look at features. As I wrote in previous blogs, today's feature means both "new features" as well as "bug fixes" due to the coolness quotient. I look at a feature in terms of what state change you are looking to accomplish in production and then plan whatever needs to be done to accomplish that.

There are also multiple ways to look at the definition of a pull request. I look at it as a package or vehicle in which a feature travels. A feature branch is the best practice that directly adheres to this principle and has become a de facto standard in a very short amount of time. A "short-lived" feature branch now lives to serve a feature and ceases to exist once a feature makes it to production.

As per Martin Fowler, the other important aspect of the Pull Request mechanism is "pre-integration reviews." Different stakeholders need to make sure that the change is doing exactly what it is expected to do. They also look at the exact change from a different lens e.g., a product manager would focus on any gaps while a security architect would focus on aspects like image scanning.

Ephemeral Environments & the "preview" stage

Now is the time to introduce the right candidate for the "everything in between" stage and that is a preview. Let's look at how the flow works:

• A feature branch is born out of the main.
• The feature gets developed in this branch.
• A pull request is created once the developer is done with the changes.
• At this time, an ephemeral environment is created in which the application is built and tested. It is done as a chore using, for example, using buildpacks for building and artillery for testing: housekeeping, no brownie points.
• Every stakeholder gets a preview URL to make sure they get to review the changes.
• The feature gets merged into the main, and the deployment pipeline gets triggered.

As you can see above, there is no need for classic continuous integration here. Some reminiscent of that can be integrated into continuous deployment as a pre-hook to deployment.

Summary

With the rise of "every stakeholder" and "change" as first-class citizens, all you need is a leading ephemeral environment as a service platform like roost.ai to make an application production-ready. To give customers an off-ramp from rustic CI pipelines, we integrate with all leading CI tools, though, in reality, you do not need any of them.?

>> Next Edition: The Birth of Preview as a Release Stage Has Humble Origins!