What Is DevOps?

DevOps is a professional, cultural movement. It not only aims at harmonizing collaboration between software development and operations, but has the broader goal of optimizing the whole software development process: from idea to delivery of a useful product or service.

DevOps tries to extend agile, which is now commonplace in software development, into the realm of operations. Lean principles, like continuous flow, build the foundation of DevOps. This is reflected in the adoption of practices like continuous delivery or infrastructure as code.

Continuous delivery enables the team to release software in small batches as soon as they're done. Immediate release of these small batches creates tight feedback loops across team boundaries which helps bring everyone together: development and operations act on shared knowledge about the current situation. This is one of the cornerstones for a successful DevOps culture.

Enable Your Teams to Rapidly Ship and Operate Quality Software

by on January 30, 2015 · 0 comments

How often do your development teams release to production? Who gets the alert in the middle of the night when everything crashes and burns? Do these questions make you uncomfortable or rather their answers? Or maybe you are already discussing changes to your current deploy process? Because it sucks, right? If you’re honest, it will always suck because it constantly needs to be adapted to the current business requirements.

Enter the “Platform Team”: a group of build & deploy experts that jumpstart your teams down the road to operational success while providing a safety net. And, no, I’m not referring to a System Administrator with a pager. Instead, I’m suggesting a three-ply construction of automation, containerization and monitoring.
[Read more…]

How Hubot Automation Crystallized Trust within our Development Team

by on February 20, 2014 · 0 comments

“Hey Dan, could you deploy the coolPics branch to test? Sorry for the bother :(”

“No problem, man. Tell me the SHA and I’ll deploy it.”

I had been having this conversation 4-5 times a day for a couple of weeks now. Being a huge fan of continuous integration, I wondered how to automate this. Why shouldn’t the developers be able to push whatever they wanted to test?

A colleague, overreading this back-and-forth in our HipChat room, told me to take a look at Hubot. It was custom made for automating rote tasks like webapp deployments. One weekend later, I was hooked. Here’s how I took the first step in transforming our abstract sense of team trust to tangible ownership.
[Read more…]

If Devs Own Testing, Ops Owns the Environment

by on July 25, 2013 · 0 comments

The devs are all writing automated tests and some are even experimenting with TDD. Congrats! But what happens when the build server breaks? Who’s taking care that Continuous Integration is running smoothly? Seems to be an awful lot of red in there…

Unlike writing the first basic tests, CI is hard. Did the test fail due to an application bug or is it the environment? Once again, the dreaded chant of “it works locally” is taken up. What most people fail to understand is that the failing test is the first sign of a communication breakdown between developers and sysadmins.
[Read more…]

Leadership In the Online Age: A Reflection On Team-Building

by on July 18, 2013 · 0 comments

In the last decade of my career, I’ve been extremely fortunate to have worked with some of the best people I’ve ever known. A big contributing factor to this is the tech-savvy, expatriate culture that exists here in Munich as well as the type of people you typically find abroad who have left their home countries to pursue their dreams. It’s a dynamic that provides an immediate and powerful bond: we have to learn an a lot of things in a short timeframe and sometimes we’re terribly homesick, but we’re not alone. When we combine our strengths and help each other, we achieve something great.

For as many teams as I’ve had the privilege of leading, I’ve often been asked how I did it? How did I take six or seven individuals from different countries and turn them into a team? The question always catches me a bit off-guard because I don’t consciously do this – and I think that’s key. You can’t force anyone to work together as a real team and the harder you try the faster you’ll push them apart. Plus, it’s currently a developers’ market. They can work wherever they want to and they know it! How do you walk this tight-rope and successfully lead a team of rockstar developers?
[Read more…]

Why Teaching Developers To Test Is A Good Investment

by on July 11, 2013 · 1 comment

Test a developer’s software and you’ll find bugs.
Teach a developer to test and they can release their software.

A bit of a twist on the old fish and eating maxim, but the same idea: teaching a skill enables self-reliance and self-confidence. And, while it’s harder than quickly doing someone a big favor, teaching is scaleable in a way that quickly refutes another old adage: we have so many bugs because we don’t have enough testers!
[Read more…]

How Value Stream Mapping can speed up your cycle time from years to weeks

by on May 30, 2013 · 0 comments

When switching on the oxygen pumps, there was an explosion on board of the Apollo 13 space craft. A short circuit in a small module led to an explosion rendering most of the space craft useless.

For days, the crew frantically worked in cramped quarters trying to return to Earth. Tensions ran high, but, instead of blaming each other for the mistakes they made, they concentrated on the system of the space craft and how to work with what was left of it. Only that broad, holistic focus on the system let them survive.
[Read more…]

How To Break Departmental Silos By Forming Feature Teams

by on May 23, 2013 · 2 comments

Imagine a seven year old playing the piano. She hits every note like it’s the only one, taking long breaks between each note. The play drags and listening to the singular notes is a pain. Instead of music, all you hear is a bunch of individual sounds, each one rivaling with the others to be the loudest one.
Now imagine the same play performed by the same kid five years later. The notes flow like a river, the emphasis not on individual sounds but on the whole sequence at once. Listening to the piece is pure joy, because every note works together with the others to create a beautiful experience.
Distributing your software development through separate departments is like a seven year old playing the piano. Every department works on its own, rivaling with the others to be the most important. The output is a pain for your customers and the quality is really poor. But how can we create an organization where the individual parts play nicely together? One way of making departments play together are feature teams. Let’s see how this could work out.
[Read more…]

3 Reasons To Avoid Overloading Your Teams

by on April 16, 2013 · 0 comments

Monday morning on the highway. Your speed: 0 mph. You’re stuck in the usual rush hour traffic jam because the capacity of this road is exceeded. And it’s now obvious you’ll reach your destination much later than if the road were empty.

But what happens if you exceed the capacity of your development team? What happens when you cram in more features than the team can develop? Your features will get stuck in development. Let’s see how this can happen.
[Read more…]

How badly set goals create a tug-of-war in your DevOps organization

by on April 9, 2013 · 1 comment

A rope. Eight people on either side. “Pull!” And then it begins: both parties are pulling in their own direction. A tug-of-war has started.

Imagine your developers and sysadmins as those two parties starting that tug-of-war

Each group has different goals. And having different goals leads to each party pulling in another direction. How can this happen and what to do about it?
[Read more…]