Wait! Just wait a dadgummed minute! It takes days to build a development environment, and now I am supposed to read an article on a disposable development environment?

Disposable DevOps Thinking

DevOps is based on five pillars:

Culture
Automation
Lean Thinking
Measurement
Sharing

Because we automate environments such that they are easy to share, we should be able to measure meaningful business impact. This model is a DevOps practice of modeling developer workflow for operational tasks.

Why a Disposable Development Environment

Log in to your workstation and delete the runtime for Java, PHP, etc. Remove, or change, a few config files and empty the trash. Now what? What if your entire team did this because they had a great idea? Panicking yet? What if getting started in any team was as easy as:

Cloning the project from source control
Starting the runtime environment
Obtaining caffeine
Getting to work

The majority of developers today have a hand-built, artisanal, bespoke workstation setups with the following characteristics:

It takes days to onboard a new team member.
Innovation around runtime environments is stifled.
Moving from one team to another is the work of days.
Workflow is more like Ops instead of Dev.

Let’s set some goals:

No more than 30 minutes for a new team member to make their first code commit.
No more than five minutes to throw away an environment and start over.
No more than five minutes for a developer to move from one team to another.
Runtime changes happen the same way as application changes.

None of this is possible unless your teams can throw away a runtime environment at will, thus disposability is an “[-ility]” that we should expect to be delivered with our software.

Disposable is Indispensable

The most important concept is handling runtime of the application with a virtual machine (VM) on the workstation. The application code remains on the workstation. This means that developers still use all the tools and workflows they have today. If a mistake happens on the VM, kill it and start over. If it happens on the workstation, then its time to rebuild the laptop.

At its core, the ideas borrows from common concepts in our production environment (and a specific tool example):

Hypervisor for supporting guest virtual machines on the workstation, such as Virtualbox
Provisioner to configure the guest machine, such as Chef
Source Control to track and manage changes to the application and the configuration, such as git
Glue so the provider and provisioner can be expressed as code and managed through source control, such as Vagrant

Onboarding a New Team Member

Have the new employee follow a set of directions. It should take no more than 30 minutes for the employee to install the tools and the application he or she is to work on. As a manager, this must be measured and tested relentlessly. New hires should be directed to keep notes on trouble spots and anything that takes a long time. They improve the documentation for the next new hire.

Accelerate Innovation

Developers say, “I wish I could upgrade to PHP X! I would be done in minutes, not days!”

Developers are capable of such an upgrade, so the real problems are:

It takes a few hours to upgrade a language version.
If the attempt fails, it could be longer to unravel all the hand-rolled changes.
If the attempt succeeds, everyone on the team is committed to undertake a fraught journey to upgrade their bespoke workstation.

With management asking about things such as feature velocity, time to value and internal hurdle rates, who is willing to take that sort of time only to succeed and cause everyone else on the team grief, too? This is why security upgrades are always done with such pain. They are delayed because they are “non-functional.”

Now abstract the runtime to a VM and the configuration of the VM to code. Assume the developer wants to upgrade PHP.

Developer destroys the current VM with PHP 5.2.6 on it.
Developer goes into the Chef code (for example) and changes the PHP version to 5.3.29.
Developer launches a new VM with a single command.
Developer runs automated tests.

The most likely outcome is some tests fail. With a bespoke environment, this is where the upgrade effort stops. Fixing all the tests is a commitment to getting the entire team to move in lock-step. On a team of just five people this is daunting. Developers are not project managers.

With a disposable development environment, it takes five minutes to make the change. Developers know it is an identical effort for their colleagues, so the thinking changes.

Given an arbitrary time window, the tests are fixed and the PHP upgrade saves the time or improves system performance or patches a security hole. To share this change across the team this same developer commits the change in the Chef code. They push it to the code repository and message the team, “Hey PHP 5.3.29 works, please adjust.” One person does all the work.

Team members stop what they are doing. They stash the work they have inflight. They pull the changes from the code repository. They start the VM and Chef configures it. They unstash their work and get back to providing business value. In less than five minutes the entire team is done.

Accelerate Security and Compliance

What if a developer’s upgrade causes security issues? Changing something as important as the language version is meant to illustrate this power. But this is not the right question to ask. Instead, ask this one, “How do we ensure we are secure before we get to production?”

Assume that any change in the development environment is reflected in production through the same process. For example, when code is deployed to quality assurance (QA), the Chef cookbooks run and they bring up the machine with the new PHP version. Why would there not be tests to show that the application is at least as secure as previously?

Even more to the point: By making it easy to upgrade the base language, test the change and share it across the team, upgrades are much less risky.

This thinking has some new assumptions:

You trust test automation at the application level. (common)
You trust the test automation at the infrastructure level. (uncommon)
You have automated security and compliance practices that check before a production release. (rare)

As managers we must help our:

Ops team becomes better at the practices of code management since the infrastructure will be code.
Development team makes responsible changes in concert with operations, security and compliance groups.
Security teams adopt a security-as-code mindset to facilitate testing before promotion from development.
Compliance team joins the development effort so changes are already part of audit output. Compliance-as-code is already on the way.

Business Outcomes of a Disposable Development Environment

We hire new people when we need them. Taking two weeks just to get into a working state means we are delaying time to value. Delaying 30 minutes is less time than filling out the HR paperwork. We need this critical time to fill the need that caused the hire.

Developers have more freedom in the infrastructure to try their ideas. The also have the safety net of putting it back like it was in less than five minutes when the idea does not pan out.

Patches to the runtime environment for security can be applied at development time where they can be tested through the full deployment cycle. This takes minutes instead of days.

If all teams are using a standard method and tool chain, then it is possible to adhere to the maxim, “Put your best people on your biggest opportunity.” Developers can move from Team A to Team B in less than five minutes and get started learning the code. They can move back in the same five minutes.

Changes in the runtime happen at development time, and they are promoted and release with the application. So, perhaps most of all, if it works on the developers laptop then it will work in production.

Without the ability to simply throw away the environment and easily start over, Dev and Ops cannot innovate toward these benefits. So go ahead and dispose of those bespoke workstations, and be sure to manage toward the benefits:

No more than 30 minutes for a new team member to make their first code commit.
No more than five minutes to throw away an environment and start over.
No more than five minutes for a developer to move from one team to another.
Runtime changes happen the same way as application changes.

Feb	MAR	Apr
	11
2019	2020	2021