OpsFirst: turning ops into a first-class citizen in your development process

We finally have the tools and the processing power to create real isolated environments that can be used seamlessly as day-to-day development envs. Nevertheless, some people still prefer to stick with older methods, for various reasons. Usually, the excuse is that it's a lot of work - having to setup and automate an environment (a VM for instance) just to start developing the application, without even knowing for sure what kind of dependencies the app will need in the nearby future - and nobody has time for that. If you think that way, this post is for you.

Written by Erika Heidi on Saturday April 11, 2015 - Permalink - Category: DevOps - Tags: devops, deployment, development - Lang: eng

In the last 10 years, the way we develop and deploy applications changed a lot. The popularization of version control and configuration management tools played a big role in this change, creating new processes and workflows that brought server and application deployment to a whole new level. This has also much to do with the fact that many developers out there aren't only responsible for coding - they are also required to take responsibility on the application deployment to production, which includes setting up the environment properly. Configuration management tools help making all this in a very programmatically way (just as developers love, of course) and this is why tools like Puppet, Chef, Ansible and Salt, just to name some, are getting so popular.

This progress is not limited to production environments. We finally have the tools and the processing power to create real isolated environments that can be used seamlessly as day-to-day development envs. Nevertheless, some people still prefer to stick with older methods, for various reasons. Usually, the excuse is that it's a lot of work - having to setup and automate an environment (a VM for instance) just to start developing the application, without even knowing for sure what kind of dependencies the app will need in the nearby future - and nobody has time for that. If you think that way, this post is for you.

Instead of going straight to the code, considering the ops part first has proven to be super efficient for me, because when the code is done I already have everything figured out for deployment. When I  say "ops" here I'm not talking about installing a LAMP / WAMP / etc in my local machine. I'm talking about really thinking through the ops aspects and having a dev environment that actually simulates what we are going to have for production, where you can easily make changes and unmake them if something goes wrong (going back to a certain previous state). We also need to assure the process of creating such environment is easily replicable, as for development these environments should be disposable and easy to share with coworkers.  For easy reference, what we want is a DRIV environment: disposable, replicable, isolated and versioned. DRIVE for short :)

I like to call this approach a opsfirst workflow. It's all about putting some effort on the ops side before even starting with code -  turning ops into a first-class citizen in your development process, from day zero.

For small teams and side projects where you are the sole developer (two types of project I'm very used to), this is extremely helpful. The time you spent to initially setup the right environment will certainly pay in the long run, when you are probably tired after months of development and all you want to see is the application going live. 

TL;DR:

opsfirst: drive4dev

comments powered by Disqus