DevOps Zone is brought to you in partnership with:

Matthias Marschall is a software engineer "Made in Germany". His four children make sure that he feels comfortable in lively environments, and stays in control of chaotic situations. A lean and agile engineering lead, he's passionate about continuous delivery, infrastructure automation, and all things DevOps. Matthias is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Dev and Ops Cooperation

  • submit to reddit

John Allspaw and Paul Hammond did a great presentation at Velocity 2009 about the tools and culture at Flickr, which enable them to do 10+ deploys per day.

My favorite quote is:

Ops’ job is NOT to keep the site stable and fast [but]
Ops’ job is it to enable the business (this is the dev’s job too)
The business requires change

They go on by presenting the dilemma of discouraging change in the interest of stability or allowing change to happen as often as it needs to. This is where they introduce their tools and culture for lowering the risk of change.

In this post I want to share with you how we use some of the tools John and Paul mention.

  1. Automated infrastructure: John and Paul say: “If there is only one thing you do…” and I couldn’t agree more. Using tools like puppet, chef or one of the many they name in their presentation to automate the live cycle of your servers is a must. I used Capistrano as a basis and built my own tool on top of it, Carpet. And I cannot imagine to install or configure my servers by hand anymore. It’s so much more robust and has so much less risk involved, I simply love it.
  2. Shared version control: We are using separate repositories for our code and our infrastructure recipes, but both are on the same github account and all team members have full access to both. As we’re only three tech guys, everyone of us does dev and ops and knows both worlds.
  3. One step build and deploy: Rake and Capistrano give us the power of building and deploying our whole app with a single command. This is so much better than deploying with rsync or manually copying things around. And it enables us to do continuous integration with Hudson, which is very nice, too.

As we’re such a small team, we’re not using any IRC or IM robots. I’m planning to introduce feature flags to be able to fine tune which features are available to whom. This would give us a little more flexibility in operating the platform. Shared metrics are already underway, we’re continuously enhancing our Nagios graphs adding technical and business metrics to them. Again something I would not like to work without anymore.

Enjoy the presentation…


Published at DZone with permission of Matthias Marschall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Timo Lihtinen replied on Wed, 2012/03/14 - 1:21pm

I think it is crucial for small and large development teams to really wake up and realize the wealth of tools that are available to help them automate their standard processes from build, to test, and deploy.

The tools available today can give even the smallest teams the freedom to focus on what is important. Automate everything that can be, so that your creativity and efforts are focused where they need to be.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.