Why your DevOps strategy should be as unique as your business
The last year pushed organizations of every size to rethink how they connect, collaborate, and deliver software. Looking at the teams behind GitHub’s 2020 State of the Octoverse report, a clear pattern emerged: the most successful adopters of DevOps treated it not as a prescribed playbook, but as a tailored strategy shaped by their own circumstances. Two customer stories illustrate the point. The Home Depot, a retailer founded more than four decades ago, moved to cloud infrastructure and gave individual teams the freedom to customize their DevOps toolchains—an approach that helped them build the capacity for same-day physical delivery to 90 percent of the US. Front, a born-in-the-cloud customer communications platform, took a different route: migrating from Chef-managed servers to Kubernetes and adopting GitHub Actions for parallel, continuous deployments.
These are two very different companies with different processes, teams, cultures, and objectives. The lesson is that treating DevOps as a uniform template misses the point. Done deliberately, your individualized approach to DevOps becomes a competitive lever—much like a proprietary supply chain or manufacturing process—that helps your team and business move ahead.
Automation is more than CI/CD
No two organizations build software the same way, and their automation needs reflect that. Take Autodesk, which standardized CI/CD best practices shared tools across its entire product organization. “We wanted to reduce duplication of efforts where everyone was building their own CI/CD pipelines and had their own CI/CD tools,” says George Swan, Senior Director of Autodesk’s Build Platform. In contrast, Netdata relies on two separate CI/CD setups for its open source solution and its enterprise offering. Senior SRE/DevOps Engineer Austin Hemmelgarn explains: “We build the open source agent nightly, with a regular release every four to six weeks to support our enterprise users.”
Limiting DevOps automation to CI/CD, however, is a narrow view. Consider security workflows. GitHub’s 2020 State of the Octoverse report found that repositories using automatically opened pull requests to fix vulnerabilities patched their software in 33 days—almost two weeks, or 40 percent, faster than teams that fixed vulnerabilities manually.
The same logic extends across the entire software lifecycle: compliance checks, team notifications, incident management, security responses, and GitOps all benefit from the same speedup. Teams at mabl, a CI/CD testing platform, quantify the impact in their own workflow. “We ship to production about 80 times a week across all our systems, so it’s important for us to cut back on any manual processes and checklists that stand in the way of catching bugs,” says mabl Software Engineer Joe Lust. “Swapping to a built-in tool like Actions cut our CI/CD costs by 30 percent, even though we’re running nearly 2.5 times more builds than we did this time last year.”
Adopting the same automation as a competitor means you’re not necessarily gaining an advantage over them at all.
Starting point and destination determine the path
DevOps is ultimately a means of delivering higher-quality, more stable software faster—in support of your business goals. But every company starts somewhere different and aims somewhere different. A nascent startup trying the experiments with processes before automating them, while an established enterprise may focus on automating existing security and compliance workflows as part of a broader transformation. These differing goals shape both how teams work and what they invest in to round out their stacks.
That is why meeting customers where they are matters. Teams at Intuit, 3M, The Home Depot, and others highlighted during GitHub Universe showed the value of integrating with the tools developers already use. As GitHub COO Erica Brescia shared in her keynote, the company has partnered with infrastructure, operations, and business process leaders—including all the major public cloud providers—so teams can bring their existing investments into the development process without sacrificing speed, stability, security, or compliance.
Culture decides what will stick
Nothing defines the success of a DevOps initiative more than the people behind it. The research of Dr. Nicole Forsgren, who previously developed the DORA metrics now featured in this year’s Octoverse findings, points to culture and community as decisive factors. By using automation to eliminate manual busywork, teams regain time for innovation, development, and collaboration—something Dr. Forsgren highlighted in discussing this year’s data.
The Home Depot offers a concrete example of the principle at scale. “We’re better at collaborating and collectively solving problems,” says Technology Fellow Chris Black. “That’s what makes us better.” The coordination extends beyond pipelines to every part of the organization—and it is precisely what makes their DevOps work.
No universal playbook
There’s no one-size-fits-all DevOps. You cannot optimize DevOps and also share it with everyone else and expect the same results. Every organization uniquely combines culture, talent, goals, and existing investments into its path to success. And the window for advantage is wide, as long as you appreciate what might be automatic is a much broader workflow. Look beyond CI/CD: there is more automation opportunity in every corner of the development lifecycle than most teams realize—and that is where your advantage lies.
