The latest expert opinions, articles, and guides for the Java professional.
As developers, we have the power to shape the world. The trouble is that to have this desired effect, we need to get our code into the hands of users. It takes effort from the Ops team, and more importantly, a lot of time from the last commit to actually releasing changes. The way we do it nowadays is not clearly advantageous, and filled with cracks into which errors can easily slip.
In this post, I’ll share the ways we’ve changed process through tools to get us to timely, and in most cases, immediate releases.
Locating the time drain
I like to divide problematic time into two categories: wasted time and delays. Wasted time can mean that you’ve picked the wrong person for the job, or that people need to reinvent the wheel over and over. In this case, developers spending time on operations infrastructure is a great example.
Let’s face it: infrastructure is not what we’re best at. The best case scenarios leave us with infrastructure getting set up multiple times, because system administrators aren’t involved until the end of the project, and our results are not solid enough for production.
That leaves us with delays. Delays are usually the disconnect between what we’d like to happen and what’s possible at the given time. We think that the new feature is the greatest contribution to the world. Management pushes another project. And operations finds the service, that just crashed, takes priority.
Luckily, these are easy issues to fix. Schedule work as early as possible, so people can work on them when they have time, and share results through tools. Sounds awfully like a pitch for provisioning tools, right? Well, not quite.
Infrastructure as code isn’t the magic bullet
The thing is, there’s a reason why this hasn’t been picked up as much as everyone would like to:
provisioning tools are made for system administrators with infrastructure in mind. As developers, we tackle problems in a different way, and we care about applications, not infrastructure.
There are tools designed exactly with this difference in mind–release management tools. Once we understood this difference, the right people started working on the right things and share the results. So, let’s move on to how it solves the time problems in practice.
What to do at bootstrap
From day one, we know the kind of application we want to build. Is it a simple Python web app or does it require a full blown Java application server? Operations teams already know the middleware they trust, and most often already have an Ansible playbook or Chef recipe ready to be reused. So while we figure out the architecture details, they prepare the infrastructure. The moment we are ready to get started, we have the infrastructure to work with as a Vagrant box. As a bonus, we get to identify and fix problems with the environment early in the project.
As we shape the project
As the application takes shape, it places more requirements on the environment. Environment-specific configuration needs to be provided, caches need to be cleared on every update, directories are needed for temporary files and so on. Instead of the regular back-and-forth with operations, we take care of it ourselves with the help of our very own release management tool, LiveRebel–eat your own dogfood and all–but think Capistrano or Bamboo deployment projects. Also, because of this, anyone can test the application at any given time, and the release process is battle-tested many times over.
Release & repeat
By the time we get our last commits in, infrastructure is ready to go from the operations POV and we’ve automated everything the application needs. Just fill in the environment configuration for the production and press release! The satisfaction comes when you understand that for the next iteration, you don’t have to worry about any of this, since everything is already set up and you just change a piece or two when needed.
While I would like a world where developers have the superpowers of system administrators and vice versa, it doesn’t really exist. The truth is that as developers we’re bad at infrastructure and operations has more urgent issues to attend to than our next feature. The key is to understand that each have their own skill set, schedule and way of solving problems. I propose that you keep dependencies between teams to a minimum and share results through tools. The combination of provisioning, virtualization and release automation achieves that for us. Now go forth, figure out where your time goes, solve your bottlenecks and change the world!
Leave me comments below, tweet at @mirkoadari, and if you’re still curious, find out more about how ZeroTurnaround dogfoods it twice a week, releasing 30+ apps without downtime for users.
No comments yet.
Leave a comment