Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

6 Keys to Unlock the Value of DevOps

DZone's Guide to

6 Keys to Unlock the Value of DevOps

Having a clear idea of DevOps and continuous integration/delivery is essential to doing DevOps right; check out these points to help you plan.

· DevOps Zone ·
Free Resource

The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.

When people talk about today's software, two things are clear:

  1. It's driving real value in businesses, big and small, helping them transform processes and create whole new app-driven business models.
  2. The IT organizations in the market-leading businesses are committed to delivering software the right way, embracing the spirit of popular practices like continuous integration, continuous delivery, and DevOps.

What's less clear is whether organizations are following the principles these practices indicate. In previous blogs, we've looked closely at the finer points of continuous integration and continuous delivery and concluded that many organizations think they're performing these practices the best way possible. But on further inspection, they aren't.

What about DevOps? Are organizations doing DevOps right? If they are doing continuous integration and/or continuous delivery right, can they still not be fully checking all the boxes for DevOps? Once again, these questions are important for organizations to sort out as they try to optimize their performance in an economy increasingly driven by software innovation.

Overall, doing DevOps correctly can be a huge catalyst for an organization. But doing it incorrectly can be counterproductive and can cost the organization in a number of ways. Here's a look at what DevOps is and how to do it right.

Defining DevOps

I like to think of DevOps, continuous integration and continuous delivery as being like software delivery siblings - all descended from the agile and lean movements that aim to streamline processes. There are differences. Continuous integration focuses on processes like automated builds and quick changes on the left side of the delivery process; continuous delivery covers best practices moving through the pipeline up to production, and DevOps focuses on the organizational change needed to support collaboration between functions. But they all tie together.

At a high level, DevOps is a cultural term. You achieve DevOps when you create a software development culture supported by technical practices. Within a DevOps culture, software development stakeholders have mutual understanding and empathy such that they are aligned on shared objectives of releasing quality software rapidly and repeatedly.

Can you do continuous integration and/or continuous delivery right and still fall short on DevOps? Absolutely. Continuous integration and continuous delivery are practices that you can implement - and even, to a certain extent, master - while not truly affecting the cultural change necessary to become a DevOps organization.

On the other hand, you really can't do DevOps right without incorporating the building blocks of successful continuous integration and continuous delivery practices. As Jez Humble likes to say, you could implement DevOps processes using a Bash script - DevOps does not inherently prescribe the component practices. But, to implement DevOps in a sustainable, repeatable and scalable manner requires commitments to continuous integration and continuous delivery.

Doing DevOps Right

There has been a lot written in recent years attempting to identify signs that your organization is either doing DevOps right or wrong. Some of the more popular traits assigned to effective DevOps organizations is that they have clearly defined DevOps strategies and can set up "common-sense" measures to identify when things go wrong. Some of the key flags for bad DevOps implementations include having no tolerance for failure and trying to bake in testing processes late in the implementation.

I would boil down the assessment to the following six recommendations, all focused on achieving a DevOps culture:

  1. Define a holistic process, from end-to-end.
    Successful DevOps cultures focus on the business, developers, testers and IT operations teams working together around shared objectives. They give their input about how to start the process, build a successful pipeline, implement a delivery process and measure the outputs.
  2. First, successfully achieve DevOps across one team.
    Before you try to achieve DevOps across your organization, you need to make sure it works on a micro scale, ensuring there is a bottom-up adoption and buy-in from key managers. Management buy-in can be difficult and time-consuming at the start of an implementation, but it will be required to successfully achieve an organization-wide transformation. It's going to affect timelines, budgets and organization.
  3. Make sure your organization is free of silos.
    Not all organizations can eliminate organizational silos. But by involving and aligning all stakeholders in the delivery process, across departments you can virtual (or actual) product teams, reducing the impact of organizational silos. This will help establish empathy between the different teams in the organization and drive a culture of collaboration and feedback.
  4. Ensure the right people have seats at the table.
    If you try to create a DevOps strategy with the input of every single team and functional group within the organization, you may get mired in overwhelming complexity - analysis paralysis - and never really get started. To get your transformation going quickly, it is best to reduce the scope, focus the initial implementation on one to a few projects. Once you are successful with those, begin incrementally scaling DevOps across teams, incorporating new input along the way. I recommend you start by gathering representatives such as management and an individual contributor from each of our processes and groups: a management rep from the business, a project management administrator, a lead developer from a development team and an actual developer. Individual contributors are integral, as only they can truly identify the pains the experience and should be improved. This also creates the necessary empathy and buy-in on the ground.
  5. Don't try to "buy DevOps."
    Some organizations operate on the belief that they can buy a set of tools which will make them into a DevOps organization. Don't fall for this trap. Tools are a critical part of connecting teams across silos and enabling the automation that supports DevOps, but tools alone will not solve your problem. You need to do all the hard work creating the culture and looping in all the important aspects of continuous integration and continuous delivery to ensure that the tools are doing their jobs.
  6. Make sure you're successfully measuring your progress.
    An effective DevOps culture includes a commitment to measure results and report on quantifiable metrics. To stand up your delivery pipeline, you need to build in the ability to do these things and continually track your progress toward those goals. For example, less than optimal software delivery processes tend to lead to significant overtime. Operations engineers and other team members tend to work long hours to get software deployed. So, measuring team hours with a goal to reduce overtime man-hours by 50-75 percent will instill the right amount of discipline and help promote a culture of excellence.

The Downside of Bad DevOps

There are consequences to doing DevOps wrong:

  • First and foremost, you're going to miss opportunities. Today's market is moving fast, and every company surely has competitors that are implementing DevOps correctly. They're innovating and gaining market advantage. If you spend time focusing on a failed or misplaced implementation of DevOps, there's a significant opportunity cost associated with that.
  • There also are internal costs. If a DevOps initiative flops, morale suffers and IT leaders may have difficulty getting the buy-in required for another DevOps transformation.
  • Then there are the actual costs. Investing in a faulty DevOps project wastes money, time and employee resources that could have been directed elsewhere.

The Upside of Good DevOps

On the other hand, successful DevOps implementations can generate significant value in the following areas:

  • Happier employees - Creating an efficient, committed DevOps organization can help companies maintain and recruit top talent.
  • Increased productivity - Less time wasted in the software development lifecycle translates into improved value in software stream.
  • Speed - The ability to innovate faster while maintaining quality gives a company a tremendous competitive advantage in the marketplace.

Conclusion

To do DevOps right, an organization needs to build multiple bridges - linking people, processes, tools and organizational goals. This is hard work. It cannot be done quickly, but it can be done if organizations commit to creating a proper DevOps culture. Don't just show up one day and say you're going to do DevOps. Use the concepts of continuous integration and continuous delivery as building blocks and get the rest of the organization to rally around your vision. Establish where are you today, where you want to go, and how you're going to get there. Then you're on your way!

Interested in Kubernetes but unsure where to start? Check out this whitepaper, A Roundup of Managed Kubernetes Platforms from Codeship by Cloudbees, for an overview and comparison of Kubernetes platforms. 

Topics:
devops ,continuous integration ,continuous delivery ,ci/cd

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}