Menu

Dont’ worry about making mistakes – as long as you don’t make them in production

You know what’s wrong with your development or integration environment? That, most probably, is “broken”. Meaning that a component isn’t working as intended, or a dependency wasn’t upgraded to the required version, or maybe a legacy application still in production is not properly initiating.

And you know what? It is completely fine. Because that’s exactly what development, sandbox, integration and all those non-productive environments are for.

The issue, however, is the time wasted trying to solve those problems. Promoting a release artifact (a candidate of your software) requires a certain level of quality, and a broken environment is hardly a valid context for validation. So, usually, the last days of a sprint are wasted in a timed race to fix all inaccuracies in the application’s ecosystem. Chances are that, in a hurry to make it work, someone broke something else. And there you have your infinite loop.

If your non-productive environment is shared amongst several teams, the concern is magnified tenfold: a configuration or prerequisite changed by the other crew now made this team’s software unusable. Then the finger-pointing and the blaming start, and toxicity levels rise. This calls for additional management and diplomacy skills.

However, there is an approach that can solve this altogether. You could define your artifact’s whole prerequisites as code, and then use that information to create from scratch the necessary hosting machine. Tools such as Ansible, Vagrant and Docker, to name a few, have very straight-forward ways to implement these essential elements to set up a self-provisioned environment. The operative system, third party libraries or even private components developed on your department can be retrieved from an internal repository to speed up this process.

Another advantage to this approach is to have “ephemeral” environments for each step of your artifact’s lifecycle. Why should you keep a machine up and running when you can fire up one anew in a matter of minutes, and then trash it when you’re done? Make the math: you’ll be saving money in costs using machines on demand.

As a final thought, consider for a minute how this approach makes the most out of Continuous Integration / Continuous Deployment tactics: with each code commit a container could be created, the artifact deployed, automatically tested, and packaged as release candidate if all quality gates are approved. Cutting out times to market release makes everyone happy: from developers to your market user base.

This strategy is called “Configuration as Code”, or “Infrastructure as Code”. And this will make sure you never worry about having errors on development, ever.

Dont’ worry about making mistakes – as long as you don’t make them in production