DevOps at Scale: Best Practices in Use Today

Source – informationweek.com

IT professionals in the field discuss some of the best practices that help to make DevOps initiatives successful.

Achieving the theoretical benefits of DevOps in practice can be hard. Plus, while much DevOps focus is on mobile, web and internal apps, it is also being adopted in many larger scale and often electronics-based projects, involving complexity, volume and compliance. We asked some of the companies we’ve been working with about their DevOps experiences and they have three stand-out themes: planning, tools and culture.

Culture

Swiss-based u-blox is a global leader in wireless and positioning modules and chips for the automotive, industrial and consumer markets. Says Stephan Uyttebroeck, Principal Software Engineer based in Belgium, “While DevOps concepts are applicable, regardless of the kind of development work involved, don’t expect to find instructions or recipes that apply to your set-up. It’s important to understand the big picture and then adopt the parts of what you learn that make sense.”

Stefan Callsen, R&D Engineer at Adtran GmbH, a global provider of networking and communications equipment, and software solutions, has been closely involved in the company’s DevOps adoption, adds, “Without understanding the proper concepts, vision and mindset, implementation may not necessarily fail, but you won’t get the maximum benefit.”

Steve Pacheco at Woodward, an independent designer, manufacturer, and service provider of control solutions for the aerospace and industrial markets, says, “It is very important to get the team on board as soon as possible and define roles up front, so they start to see the value early. We were able to get team buy-in quickly, which helped us better deal with some of the challenges due to the fact that our projects vary quite a bit. Customer involvement helps too, but that’s not easy to achieve.”

Planning

Larger scale DevOps projects – those found in the electronics-based industries of the companies we interviewed – are more challenging than single team DevOps, because of greater complexity of requirements, yet the need for flexibility and support for “what if” analysis to ensure teams get a clear picture of the anticipated outcome.

Some teams are now embracing methodologies like SAFe, (Scaled Agile Framework, a set of integrated and modular patterns designed for enterprise-scale Agile adoption). Adtran is a case in point. Says Callsen, “We are currently implementing SAFe 4.5. In that framework, DevOps is not considered a team activity any more, but shows up as a mindset, though in practice, it is a combination of the two. Don’t forget to integrate DevOps in the planning process and encourage development teams to name their dependencies to specific DevOps methods rather than having each team defining their own CI or whatever. This is especially important when it comes to company-wide integration of artifacts from globally distributed teams, because building enterprise standards for code sharing dramatically improves build reproducibility, leading to better quality and productivity. A common understanding across teams, and a supporting DevOps community is key.”

Sometimes, an entire project might be something of an unknown. This was the challenge facing u-blox, which implemented DevOps for the development of a new LTE Cat 1 wireless modem a couple of years ago, one of the most ambitious projects in its history. Says Uyttebroeck, “We had to start the projects before we had clear software and hardware specifications, so we knew we would have to make changes as we went along. DevOps gave us agility and control across hundreds of contributors in multiple teams. DevOps enabled us to achieve far more than would otherwise have been possible within the time constraints.”

Tools

While DevOps is essentially a methodology, tools play a major role. Adtran’s Callsen says: “It is almost impossible to keep up to date and be aware of their pros and cons. So, don’t be afraid to stick to your tools decision if these fit your environment and fulfill your needs, now and in the future. Nevertheless, stay tuned to the outside world.”

“External consultation helps focus your vision and gets you off on the right foot, says Woodward’s Pacheco, “We brought in a consultant to help us get the most out of Helix ALM. He spent four days analyzing what we were doing and then spent 46 hours re-configuring the environment.”

Uyttebroeck explains how u-blox gave users guidance over tools without mandating their usage, “Rather than enforcing particular tools, we gave people guidelines, best practices and lead by example, but also gave them flexibility and responsibility. If a team finds transition to a new tool is too much for them, we allow them to step back and reduce the level of interfacing and delivery, as long as they take responsibility for ensuring what they deliver works with what other teams are delivering. The majority of users chose the recommended tools in the first place, and even the ones who initially stayed with their chosen toolset have gradually made the transition.”

Finally, Adtran’s Stefan Callsen says: “Do not underestimate DevOps tasks and allocate proper resources to achieve your goals.” Steve Pacheco of Woodward: “Think of the long-term: today’s existing projects are tomorrow’s historical projects, they need to be maintained and leveraged for re-use.”  Finally, Stephan Uyttebroeck from u-blox: “Just do it, but keep flexible, agile and continuously look to improve.”