What does it take to bring about a DevOpsian culture? Business and IT leaders now say they are practicing DevOps, in which the talents and output of their development teams are coordinated to meet the ever-increasing cadence of software updates. Recent surveys show that while a majority of organizations say they are now practicing DevOps, most haven’t fully implemented DevOps because they haven’t figured out a way to bring it all together. Only about one in five have merged their teams for managing infrastructure, operations and development.

Photo: Joe McKendrick

DevOps means transformation across enterprises, versus deploying some shiny new tools or technologies. Sacha Labourey, founder and CEO of CloudBees and Jenkins proponent, says larger enterprises are having a difficult time with making DevOps work as expected. Within larger organizations, “it’s just harder — size is in itself is a factor of inertia,” he says. “Silos are much stronger.. so even if there a mandate from the top down to changes, it just takes a lot of energy and time to fight all of those headwinds.”

I recently had the opportunity to sit down with Labourey at CloudBees’ recent JenkinsWorld conference in San Francisco., where he shared his views on DevOps and the movement toward software automation. DevOps proponents need to “think about how they can standardize, normalize, empower, how they can onboard more users onto their strategy,” he says. “You have multiple waves of adoption — learning how to do DevOps, how to get started, and how to make your projects more successful. Another is to offer DevOps as a service. It’s a journey, not a switch you can turn on to enable things. There’s much more to it.”


The trend toward DevOps has been accelerating because companies are feeling the heat of market disruption, Labourey says. “We’ve been talking to companies for a long time, how they need to becomes software companies, blah, blah,” he says. “We realized it doesn’t work. Only one thing works, which is competition. Once you see a maverick come into your space, and leverage software to beat you, then that’s a wake-up call. We’ve seen those waves of companies adopting DevOps threatened by software-led companies.”

At the same time, organizations shouldn’t panic and attempt to put DevOps in place in a rush. There’s “a lot of rewiring” required to fully embrace DevOps, he continues. “You want to know about quality, and what it means to rearchitect an application. There is an extreme amount of knowledge that’s required. There’s change management, and explaining why, in the long run, there’s a benefit. It’s very hard to achieve DevOps without getting buy-in from management, because there’s only so much you can do.”

The main issue Labourey sees with DevOps implementations at this time is DevOps thinking is remaining confined to IT departments – even if Agile methodologies are employed. “At the end of the day, it may not matter, because in some organization we see transformation happening very locally, as in engineering. Unless the business is truly affected, DevOps is not going to truly be a game changer. If you receive requirements to cycle a project in 18 months, and if it’s a bad idea, you’re going to fail in 18 months. Even if you have six iterations, you’re still going to fail in 18 months if it’s still a bad idea. You want to make sure that during these iterations, you can raise a red flag and say, ‘were going to the wall here and were going to fail.'”

That’s why a continuous integration and continuous delivery approach is key to DevOps, he states. “I think its very hard for DevOps without doing CI/CD. It’s the common thread of how to do DevOps the right way. You want to automate, you want to essentially encode the way you do your software.”

Software development and deployment has historically been an inefficient process for enterprises, he continues. “The first automobile assembly line was built over 100 years ago, and now our industry is finally starting to build our own version of an assembly line.”

DevOps with CI/CD paves the way to more automated — and scalable — software delivery. Without CI/CD, “you’re going to have people manually do things, and somehow have them somehow magically have the knowledge,” Labourey says. “You don’t want to be dependent on anybody’s specific knowledge. That’s where this notion of robots in CI/CD comes in. It means governance. If I want to change a process, then I modify the process definition, this workflow logic, and I can version this workflow logic, and see if my new workflow still leads to those attributes to be expected. Its radically changed the notion of certification of software, or compliance.”

(Disclosure: I was a guest at JenkinsWorld, mentioned in this article.)

Source link