Everyone’s hollering “devops” so much these days, you might be ready to give in and go buy a box of it ... except that devops, for the most part, doesn’t come in a box.
Sure, a bunch of tools can help a devops-centric organization work more smoothly, but the heart of devops is in the teams that implement its philosophies. Implementing devops means embracing new—and sometimes scary—strategies for team organization, responsibilities, and expectations. Here are three signs you’re on a devops team that’s pointed in the right direction:
1. Product-based teams
A true devops organization will typically organize IT teams around the products those teams deliver. That means abandoning the old discipline-silo approach that most of us have used for decades. A devops-style product team (like this) will include such roles as product managers, developers, infrastructure experts, systems administrators, and everyone else needed to make that product become a production reality.
Of course, that doesn’t mean you need a dedicated expert for every project. It’s not unusual to have a single network infrastructure expert serve on multiple product-based teams, for example, sharing his or her time as needed based on organizational priorities.
There’s also still plenty of value in discipline-specific coordination. Having all the sysops maintain a high-level view of everything that’s happening can ensure smooth operations, and having all the developers occasionally “huddle up” can make it easier to share new techniques, lessons learned, and other valuable information. That happens in cross-product guilds, where members of each discipline occasionally get together to talk shop and share information.
2. Failing with style
True devops teams don’t try to prevent failure by slowing the rate of change. Instead, they move quickly—and trust their team’s ability to recover from failure as quickly. By deploying products in small, controlled sprints, teams know that the number of changes being deployed at any given moment will be minimal, thus mitigating risk and making quick recovery easier.
Devops teams welcome failure as a significant learning experience. Thanks to automated delivery pipelines and automated unit testing, each failure becomes another test that gets incorporated into the build process. Rather than rely on institutional knowledge and experience to prevent the same failure in the future, devops teams code everything into their processes, automatically preventing the same failure from happening twice.
A devops team still tries to anticipate and prevent as much failure as possible in a proactive sense, but doesn’t shy away from the occasional hiccup, either. Culturally, this means organizations have to adopt a mature attitude about failure, eliminate “the blame game” from the culture, and focus on anticipation, learning, and prevention as a deeply rooted part of their process.
3. Obsessive automation
A real devops team knows that human error is the biggest point of failure in any process—and the biggest bottleneck to moving quickly. These teams adore automation, both for its unfailing consistency and for its incredible speed. From code check-in rules and analysis to test environment spin-up to actual unit testing to final production deployment, these teams know that automation is the only way to go.
But a truly effective devops team isn’t particular about its automation tools or technologies. They focus on the right tool for the job, and they’re willing to step away from one tool and adopt another if it provides a smoother path to the business goal. “Heterogeneous” begins to describe the average devops shop. That can be a huge challenge for legacy organizations with a deep philosophical commitment to a particular platform or approach.
Effective devops teams know that the point of IT is to deliver applications and services to their users–delivering user experiences, not features alone–and everything in between is a lot of potential for speed bumps. They know that the job of devops is to provide the smoothest, safest, fastest, and most reliable path between developers’ keyboards and a production deployment, so each new coding sprint can quickly result in a tested production deployment.
Devops isn’t “no-ops.” Instead, it’s an obsessive effort to automate as much of ops as possible.
Devops is a major shift
For companies that abhor and control change, rely on manual deployments, focus heavily on manual QA processes to catch problems, and maintain a silo-based organizational chart, devops can come across as strange, controversial, or even crazy.
But trust me—some of today’s most agile, fast-moving technology companies rely on devops-style approaches to put more product into the hands of their customers than ever before. They’re doing so with less internal bureaucracy, a stronger focus on results and customer experience, and generally speaking, happier technologists with less employee turnover.