Two Real-world DevOps Journey Transformations

Let me switch gears and talk about two Keysight software products and their journey on DevOps, how DevOps transformed them. This is about let me give a first of a kind of overview. It's almost like 250 software developers, very complex products here we are talking, more than 50 million lines of code, multiple components, in fact, more than 300-400 components, 90 + Jenkins jobs, 96 + builds, and built times ranging from 4 to 5 hours on average. And their objectives when they started the DevOps transformation were how do we give rapid software development to our customers with a predictable pace and high quality?

These two words predictable pace and high quality are very important because if you're just giving rapid software delivery, the customers are not going to be happy. Always remember that pizza, experience if the quality is not good, even if you are giving in 15 minutes, it doesn't matter. And how do we scale this out to multiple customers? It's not just about one customer but hundreds of customers. How do we scale this out? The key challenges that we listed were lack of continuous integration and lack of build elasticity. And what I mean by build elasticity is at the stages of when you are working on your software development, there are times when you need a lot of compute power for your builds, and your tests are increasing, having not just a normal unit test or integration test, but you are kind of bumping in terms of performance tests, integrate system tests.

You need more compute power in different times of your life cycle of the project. So lack of build elasticity was another one, a lack of continuous testing. There was testing happening, but it was still manual in nature while in ... if you are talking about rapid software delivery, continuous testing and automated testing is the way to go. So I'll come to what we did here, but let's first talk about the results they achieved in their DevOps journey. They got 9x faster releases, 8x improvement in quality, 2 weeks of release cadence, and continuous high-scope delivery. And they were able to do that because of the elasticity of build power or compute power. They got 3x more concurrent builds happening.

They also automated 85% of the test and reduced build time and cycle time also by 30 and 40%. So what did they do? They followed a very common approach where they said, let's go with the 8-step Kotter's model basically, which talks about leading change. They really got the first thing was they listed what is the current state and created a sense of urgency. And that whole state was really focusing on customer viewpoint, and they got really lot of customers, kind of customers involved in terms of understanding, making sure what is the before state and what the after state should look like. And they started working on kind of taking a quick win. It was 257 software developers. So instead of doing that, they said, let's start with a quick win.

Let's start with a smaller chunk first and get a quick win. And then we scale this out throughout this business unit in terms of making sure the CI/CD is happening. So the after-state included, they got more than 160 components migrated to continuous integration and continuous development pipelines. They have 85% of their test automated. They are using the private cloud or kind of VMs scalable, for their build and test needs. They are using all the modern packaging techniques like NuGet, Conan, and Chocolatey for the same.

For the planning, they are using JIRA, Confluence, and Bitbucket kind of tools for the same. The big lesson learned is the center point has to be customers. Even if it's a DevOps transformation, customers should be the central point. And you should have a leadership commitment to make this happen. And even if there is a leadership commitment, this is a shared responsibility. Every developer and every team should feel that they own, they have a stake in the DevOps transformation.

Process automation plays a very key role and always measures because the moment you start measuring, when you look at the business results, then it becomes so viable in terms of the benefits of DevOps which can come on.

As I said, DevOps is a journey, not a destination. It evolved from many disciplines like agile and continuous delivery and automation play a key role. Thank you so much. Bye bye.

Comments are closed.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}