Category: DevOps

Tools are inherent to our jobs, inherent to how we solve the problems we face each day. Our comfort level with the set of tools that are available to us, and our ability to adapt to new tools as they evolve and shape our thoughts and ideas. The availability of collective knowledge within the palm of your hand combined with the collaboration across organization and company boundaries through open source software is dramatically disrupting the status quo of work. Companies mired in managing infrastructure configuration management by hand with unknown numbers of divergent systems, unable to quickly change and respond to market demands will struggle against their counterparts who have managed to contain their complexity on one axis through infrastructure automation. While it is possible to manage servers by hand, or even artisinally crafted shell scripts, a proper configuration management tool is

invaluable especially as your environment and team changes.

Even the best software developers will struggle if they are working in an environment without a version control system in place. Tools matter in that not having them, or using them incorrectly, can destroy the effectiveness of even the most intelligent and empathetic of engineers. The consideration you give to the tools you use in your organization will reflect in the overall organization’s success. You’ll find that what is a good tool for some teams might not be a good one for others. The strength of tools comes from how well they fit the needs of the the people or groups using them. If you don’t need feature X, its presence won’t be a selling point when considering which tool your organization should use. Especially in larger organizations with teams numbering in the dozens, finding one tool that meets the needs of every team will be increasingly difficult. You will have to strike a balance between deciding on one tool that will be used across the entire company consistently and allowing more freedom of choice among individual teams. There are benefits to both the consistency and manageability that comes from having only one tool in use in an organization, and also from allowing teams to pick specific tools that work best for then.

Because DevOps is a cultural shift and collaboration (between development, operations and testing), there is no single “DevOps tool”: it is rather a set (or “DevOps toolchain”), consisting of multiple tools in the Delivery and Deployment pipelines. Generally, DevOps tools fit into one or more of these categories, which is reflective of the software development and delivery process:

• Plan – Planning Tools
• Code — Code development and review, version control tools, code merging;
• Build — Continuous integration tools, build status;
• Test — Test and results determine performance;
• Release — Change management, release approvals, release automation;
• Deploy — Infrastructure configuration and management, Infrastructure–as–Code tools;
• Operate and Monitor — Applications performance monitoring, end–user experience.

Though there are many tools available, certain categories of them are essential in the DevOps toolchain setup for use in an organization.

Tools such as Docker (containerization), Jenkins (continuous integration), Puppet (Infrastructure-as-Code) and Vagrant (virtualization platform)—among many others—are often used and frequently referenced in DevOps tooling discussions. Typical stages in a DevOps toolchain looks like this

A sustainable, successful business is more than the development and operations teams. Limiting our thinking to just those teams who write software or deploy it into production does the entire business a disservice.

The 2015 State of Devops Report, published by Puppet, found that companies that are doing devops are outperforming those that aren’t. that an emphasis on having teams and individuals work together effectively is better for business than silos full of engineers who don’t exactly play well with others. High-performing devops organizations deploy code more frequently, have fewer failures, recover from those failures faster, and have happier employees. trend of focusing on outcomes rather than people and processes.

Focusing on the culture and processes encourages iteration and improvement in how and why we do things. When we shift our focus from what to why, we are given the freedom and trust to establish meaningfulness and purpose for our work, which is a key element of job satisfaction.

The introduction of devops has changed our industry by focusing on people and processes across roles to encourage collaboration and cooperation, rather than competing with specialization.

As we said, our goal as software professionals is to deliver useful, working software to users as quickly as possible. Speed is essential because there is an opportunity cost associated with not delivering software. You can only start to get a return on your investment once your software is released.

DevOps principles can also be applied to the business

DevOps is not just support IT. DevOp scan also be used to support the business strategy and to improve business processes. DevOps applies agile and lean principles across the entire software supply chain. It enables a business to maximize the speed of its delivery of a product or service, from initial idea to production release to customer feedback to enhancements based on that feedback. Because DevOps improves the way that a business delivers value to its customers, suppliers, and partners, it’s an essential business process, not just an IT capability.

Enhanced customer experience

Delivering an enhanced (that is, differentiated and engaging) customer experience builds customer loyalty and increases market share. To deliver this experience, a business must continuously obtain and respond to customer feedback. This requires mechanisms to get fast feedback from all the stakeholders in the software application that’s being delivered – customers, lines of business, users, suppliers, partners, and so on.

In today’s world of systems of engagement (see “ Understanding the Business Need for DevOps ,” earlier in this chapter), this ability to react and adapt in an agile manner leads to enhanced customer experience and loyalty.

Increased capacity to innovate – Repeatable, reliable, and predictable

Modern organizations use lean thinking approaches to increase their capacity to innovate. Their goals are to reduce waste and rework and to shift resources to higher-value activities.

Faster Time to Value

Speeding time to value involves developing a culture, practices, and automation that allow for fast, efficient, and reliable software delivery through to production. DevOps, when adopted as a business capability, provides the tools and culture required to facilitate efficient release planning, predictability, and success. The definition of value varies from organization to organization and even from project to project, but the goal of DevOps is to deliver this value faster and more efficiently.

Companies using DevOps are outperforming those who are not

Lot of studies have proved that the companies who are using DevOps outperform the ones who do not. The 2015 State of Devops Report, published by Puppet, found that companies that are doing devops are outperforming those that aren’t. that an emphasis on having teams and individuals work together effectively is better for business than silos full of engineers who don’t exactly play well with others.

The DevOps movement is young and still emerging, especially among enterprises. Like any new movement or trend, it has attracted myths and fallacies. Some of these myths may have originated in companies or projects that tried and failed to adopt DevOps. What’s true in one situation, however, may not necessarily be true in others. Here are some comm. on myths about DevOps — and the facts:

DevOps Is Only for Web based organizations

What is generally referred to as DevOps originated in “born on the web” companies (companies that originated on the Internet) such as Etsy, Netflix, and Flickr. Large enterprises have been using DevOps-aligned principles and practices to deliver software for decades, however. Furthermore, current DevOps principles, have a level of maturity that makes them applicable to large enterprises that have multiple-platform technologies and distributed teams.

DevOps Is Operations Learning How to Code

Operations teams have always written scripts to manage environments and repetitive tasks, but with the evolution of infrastructure as code, operations teams saw a need to manage these large amounts of code with software engineering practices such as versioning code, check-in, check-out, branching, and merging. Today, a new version of an environment is created by an operations team member by creating a new version of the code that defines it. This doesn’t mean, however, that operations teams need to learn how to code in Java or C#. Most infrastructure-as-code technologies use languages like Ruby, which are relatively easy to pick up, especially for people who have scripting experience.

DevOps Is Just for Development and Operations

Although the name suggests a development-plus-operations origin, DevOps is for the whole team. All stakeholders in the delivery of software — lines of business, practitioners, executives, partners, suppliers, and so on — also have a stake in DevOps.

DevOps Isn’t for ITIL Shops

Some people fear that DevOps capabilities such as continuous delivery are incompatible with the checks and processes prescribed by the Information Technology Infrastructure Library (ITIL), a set of documented best practices for IT service management. In reality, ITIL’s life-cycle model is compatible with DevOps. Most of the principles defined by ITIL align very well with DevOps principles. ITIL has, however, received a bad reputation in some organizations due to being implemented predominately with slow, waterfall processes that didn’t allow for rapid changes and improvement. Aligning such practices between development and operations is the essence of DevOps.

DevOps Isn’t for Regulated Industries

Regulated industries have an overarching need for checks and balances and for approvals from stakeholders who ensure compliance and auditability. Adopting DevOps actually improves compliance, if it’s done properly. Automating process flows and using tools that have built-in capability to capture audit trails can help. Organizations in regulated industries will always have manual checkpoints or gates, but these elements aren’t incompatible with DevOps.

DevOps Isn’t for Outsourced Development

Outsourced teams should be viewed as suppliers or capability providers in the DevOps delivery pipeline. Organizations should ensure, however, that the practices and processes of the supplier teams are compatible with those of their internal project teams. Using common release planning, work-item management, and asset repository tools significantly improves communication and collaboration between lines of business and supplier and project teams, enabling DevOps practices. Using application release management tools can greatly improve an organization’s ability to define and coordinate the entire release process across all participants.

No Cloud Means No DevOps

When you think of DevOps, you often think of cloud because of its ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting days/weeks for a manual request to be fulfilled. However, cloud isn’t necessary to adopt DevOps

DevOps Isn’t for Large, Complex Systems

Complex systems require the discipline and collaboration that DevOps provides. Such systems typically have multiple software and/or hardware components, each of which has its own delivery cycles and timelines.  DevOps facilitates coordination of these delivery cycles and system-level release planning.

DevOps Is Only about Communication

There is a misconception that communication and collaboration solve all problems. DevOps depends on communication, but better communication coupled with wasteful processes doesn’t lead to better deployments.

DevOps Means Continuous Change Deployment This misconception comes from organizations that deploy only web applications. The concept here is about being ready to deploy when the business thinks it is the right time and not when the code is ready.