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

DevOps for Adults

DZone's Guide to

DevOps for Adults

Despite being around for several years, there are still misunderstandings around what DevOps is. See how culture, automation, and more are part of the puzzle.

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

It is 2018, and although the term DevOps was coined nine years ago, there are still a lot of misunderstandings of what the essence of DevOps is. Meanwhile, a lot of companies plan to implement DevOps, or did implement it already, successfully, in order to profit from its advantages. Thus it is time to summarize the key parts again, which you will see in this post. I will give you some pointers to follow-ups, too. Now, let's start with a quick introduction.

Introduction

The term DevOps is a blend of development (representing software developers, including programmers, testers and quality assurance personnel) and operations (representing the experts who put software into production and manage the production infrastructure, including system administrators, database administrators and network technicians). DevOps describes practices that streamline the software delivery process, emphasizing the learning by streaming feedback from production to development, by streaming good practices from development to operations and improving the cycle time. DevOps does not only empower you to deliver software more quickly, but it will also help you to produce higher-quality software that is more aligned with individual requirements and basic conditions.

DevOps encompasses numerous activities and aspects, including:

  • Culture: People over processes and tools. Software is made by and for people.
  • Automation: Automation is essential for DevOps to gain quick feedback.
  • Measurement: DevOps finds a specific path to measurement. Quality and shared (or at least aligned) incentives are critical.
  • Sharing: Create a culture where people share ideas, processes, and tools. This can also mean that teams grow aligned with t-shaped skills, see Figure 1.

Image title

Figure 1: DevOps includes sharing knowledge and experience, across teams and inside a team, while still appreciating classic division of work.

One factor of DevOps initiatives is spanning functions, which is covered next.

DevOps Spanning Different Functions

Agile efforts often end at the transition phase from development to operations, shown in Figure 2. DevOps broadens the scope to also include delivery of software and services. DevOps provides patterns to foster collaboration among project stakeholders and uses processes as well as tools to streamline the software delivery process.

Figure 2: DevOps enriches agile development by including the last mile, that is operations.

DevOps has strong interfaces to many disciplines, above all business; see Figure 3. Also configuration management, release management, test management, build management, integration management and deployment management are involved and cross-cutting non-functional requirements such as security are surely still important with DevOps. In other words, DevOps is a means to cover the entire agile Application Lifecycle Management (ALM).

Figure 3: DevOps brings together many different functions, above all development and operations, and business is always involved.

The comparison of tasks and views of development and operations shows that the two teams have divergent goals and incentives and that these divergences lead to conflict. Development strives for change (e.g., new features and bug fixes), whereas the operations team strives for stability. Often, those groups are paid precisely for these tasks: development obtains bonus payments if the software is delivered, whereas operations is rewarded if production systems are stable. The development department desires a high flow of newly provided functionality, whereas the operations department prefers to avoid putting any new release into production.

Both teams follow their respective goals by focusing on their individual tasks and by fulfilling their obligations to obtain positive attention from management and visibility for doing a great job. To achieve their respective goals, development and operations often use their own processes and tools - sets of processes and tools are optimized locally (for each group) to obtain the best local result. Although these approaches are great from their isolated viewpoints, the total flow of software is reduced, and the overall project (or company) goal is thwarted. As a result, silos are constructed, conflicts exist on a daily basis and people are working against one another instead of with one another to provide the best solution possible.

Using the right DevOps enablement tool for a specific job can already boost productivity. Enterprises will gain the maximal value of DevOps if they align goals, processes, and tools, across functions, what is covered next.

The Essence of DevOps: Goals, Processes, Tools

One key aspect of DevOps is using and optimizing shared goals. The cycle time is a shared goal between different functions above all of development and operations. It expresses that you are flexible in delivering high-quality changes, quickly. It fosters a competitive advantage. It measures the time from start to end of a process. Although creating your own definitions helps, often used endpoints include the time from Git push of a change to deploying it on production, available for end users. The cycle time is often visualized and then improved by deriving pipelines from value stream maps. Pipelines are doughnuts, not tubes - tools are glued together, based on Jenkins and quality gates are utilized while implementing a high degree of automation.

To establish shared goals, concepts and tools are very important. It is essential to choose good DevOps practices and to integrate DevOps enablement tools. Taking the right tool, aligned with your processes, requirement, and basic conditions, and integrating it with ecosystem, i.e. platforms and tools used by you, should be strongly aligned with organizational as well as technical and regulatory drivers; see Figure 4

Figure 4: DevOps is also about tools, and integrating those tools with others to work productively. Finding the correct tool depends on many aspects including organizational, technical, and regulatory drivers.

To give you one example: Jenkins could be the best choice in many setups, whereas in others the CloudBees Jenkins Enterprise tool could be the better choice to make Jenkins "enterprise-ready," e.g. by providing additional features or implementing specific non-functional requirements for security, scaling and resilience, on cloud-native, Dockerized platforms. CloudBees developed the DevOps Maturity Model to help you to find the best tool, delivers a huge set of DevOps entry points and those facets are discussed in DevOps Radio continuously.

Summary

This closes my quick discussion of DevOps. There are more aspects, and many more details. In following contributions, I'd like to zoom into different aspects of what makes up DevOps, and will discuss DevOps practices and DevOps enablement tools in more detail, also emphasizing tool integration in order to implement your holistic DevOps initiative.

Happy DevOps!

Resources

Michael Hüttermann, Agile ALM, Manning, 2011.

Michael Hüttermann, DevOps for Developers, Apress, 2012.

Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement, North River Press; 30th Anniversary Edition edition, 2014.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:
devops ,automation ,software development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}