Bringing Dev and Ops together

Originally posted on the Puppet blog, and republished here with Puppet’s permission.

You want to create a much closer working relationship between your IT operations team and the software development team. How do you do it? Here are a few highlights from Puppet’s ebook, Get Started with DevOps: A Guide for IT Managers around fostering collaboration between teams and easing the transition.

Collaboration over contract negotiation

One of the tenets of the agile manifesto is “customer collaboration over contract negotiation.” This also applies to the relationship between development and operations teams. Devote some time to helping the dev team; for example, instead of holding meetings to set some minimum performance measures, pair with the dev team to help them measure, and then improve, application performance. Pairing is a great way of starting collaboration across teams — and the dev team will likely be happy for the help.

Security is a great icebreaker

Ops teams have a healthy fear of real-world users and a good eye for security issues—for good reason. Developers are interested in security, but don’t always have expertise in it. That’s why security can be such a good place to start. Your ops team can offer internal training sessions on security, and invite developers into threat briefings. Show devs the monitoring data around malware or DOS attacks. By giving people common information, you’ll help people appreciate each other’s expertise and build relationships between the teams.

Building self-service platforms

It’s increasingly common for operations teams to be internal service providers. Rather than having your ops team deploy everything, develop a standard way for developer to deploy their own applications. Rather than the ops team being the only people who have access to production monitoring, the team can instead maintain the monitoring system and provide self-service access and training to devs.

This won’t happen overnight. Start by identifying largely repetitive work that is ripe for standardization, and then design a service model around that activity. Repeat for other common activities. The shift to self-service will fundamentally change the relationship between Ops and Dev, from operators slowing developers down to operators empowering developers.

You built it, you run it

The best people to support a complex application are the people who built it. Help development monitor and support their applications. Once the development team knows they will be directly responsible for any problems in production, they are much more likely to make sure the software is operable, stable and resilient to failure.

This doesn’t mean traditional operations skills aren’t needed. It might mean the team structures change, and that the organization moves towards cross-functional teams of developers and operators. Ops might also become a smaller services team for the entire organization, setting standards and offering their expertise and advice when needed.

Managing change

There are a few things you can do to help both your own operations team and the development team transition to the new way of doing things. Here are a few ideas:

• Developers often underestimate — or simply aren’t aware of — the parts of operations and service management that aren’t strictly about code deployment. The ops team can train developers on things like capacity planning, incident management or auditing requirements, preferably through pairing. Most people learn better by working with someone, and pairing is a great way to develop greater empathy between teams.

• Involve the development team in designing shared services — after all, what your operations team members want may not align with what the developers feel they need. Start by clearly defining user needs, and work out what’s possible in the short term and medium term. Involving both teams should lead to a better service and a better understanding of the underlying problems and tradeoffs.

• Include developers in on-call rotations. The main benefit here is in aligning incentives; it’s a lot harder to consider actually shipping software that has performance or stability problems if you know you’re going to be called when things break.

The above are just a few practical ideas you’ll find in Get Started with DevOps: A Guide for IT Managers. Read it for more help in winning over your own operations team, the development team and executives to the DevOps way of working.