DevOps Is More Than CI/CD: What GitHub InFocus Covers This Week

GitHub InFocus, the company's global virtual series for software teams, kicked off last week with a look at developer experience and innersource. This week's focus shifts to DevOps, with hosts Jennie, Marko, and Daniel previewing sessions that run from March 2 at 9am PT / 12pm ET. The conversation covers familiar ground—CI/CD, automation, DevSecOps—but also asks whether DevOps has reached its ceiling and how innersource fits into the equation.

Why DevOps Still Needs Explaining

DevOps has been around for over a decade, yet it remains "convoluted to many," according to Jennie. The week's four sessions aim to cover not just the fundamentals, but also the motivations for change, industry trends, and how to start a transformation journey. The material draws from GitHub's experience working with customers, bringing in experts from across the company to share lessons and best practices.

Part of the challenge is that DevOps is broader than most people assume. It spans tooling, development, operations, automation, and culture—and it's the methodology that binds them together. Jennie points to several unresolved areas that keep the discipline from plateauing:

  • The risk associated with moving fast
  • Optimizing and securing the use of open source
  • The impact of remote work on DevOps
  • Adopting new trends and best practices

These topics come up throughout the week, including in a "Breaking down DevOps" session with Bryan Liles from VMware.

Security as a Developer Responsibility

One consequence of DevOps is that specialist groups are shrinking and more responsibility falls on developers to deliver better software faster. Security is a prime example. Rather than being applied late in the software development lifecycle, finding vulnerabilities at development time is becoming a developer concern. The problem: security researchers are rare and expensive, so their expertise needs to scale across organizations.

Daniel's framing is that a vulnerability is often just a code quality issue that a bad actor can exploit. Treating it that way—bringing rapid code quality feedback into the branch, commit, and pull request cycle—makes security feel like just another test result to address. When that feedback is phrased in developer terms rather than security-speak, it's easier to digest, and other developers who see the instant feedback can learn collectively instead of singling out one person for a mistake.

What Innersource Adds to DevOps

Competition for developer talent is global, and even traditional organizations are leading in developer hiring compared to their digital-first rivals. Large organizations need to do more with the same or fewer resources while managing distributed teams and remote work. Open source helps by letting companies release code that isn't critical to their business or intellectual property—but that doesn't solve the problem of getting faster with the code they do need to write.

Innersource is the practice of taking lessons from open source communities and applying them internally. Open source communities have dealt with scarce, distributed resources by building shared discovery of code and process, automating testing, providing rapid feedback, and fostering open, supportive cultures. InFocus will cover how to set up an innersource program, why it's a factor in DevOps, and how it creates a feedback loop that brings open source philosophies back into internal development.

Different Organizations, Different DevOps

Everyone does DevOps differently, and Marko argues that's a good thing. A startup focused on experimentation operates differently from a large organization with years of security and compliance requirements. Both may share the same goal—shipping great customer experiences—but the path there doesn't have to match. DevOps best practices are worth learning from each other, but staying competitive means focusing on the processes unique to your business.

Sessions with Skyscanner and Otto Group demonstrate this variety, showing two organizations with successful DevOps programs and how they define and measure success.

Automation Beyond Build and Deploy

CI/CD automation is one part of DevOps, but many other parts of the software lifecycle can be simplified. Marko points to compliance checks, team notifications, and vulnerability fixing as candidates. If developers are spending more time fixing security issues than writing code, that process can be automated. Similarly, GitHub Actions and integrations allow developers to comment on Jira tickets from within pull requests without switching context.

The broader theme is identifying where teams spend the most time and using one platform to automate and manage as much of that as possible.

Developer-First Isn't Developer-Only

Three key messages emerge from the hosts:

  • Tools and platforms influence how teams work, which over time shapes culture—and culture can become a competitive advantage (Jennie).
  • Removing blocks and bottlenecks to help developers produce better code faster benefits operations, security, feedback loops, and customer success—developer-first doesn't mean developer-only (Daniel).
  • Waiting for the perfect moment to adopt DevOps or automation may mean waiting forever. Change creates friction, but giving teams space to experiment, listening to developers, and gathering feedback continuously helps find the balance between efficiency and trust (Marko).