Your guide to DevOps automation and CI/CD at GitHub InFocus

Last week we kicked off GitHub InFocus, a global virtual series just for software teams. We discussed the importance of developer experience and innersource—and how key collaboration really is. Next up: DevOps. We checked in with virtual hosts Jennie, Marko, and Daniel for a quick Q&A on what to expect, from CI/CD to DevSecOps.

This week of InFocus is a little different than the last. While ‘developer experience’ is a newer concept, we’ve known about and been doing DevOps for over a decade. So what’s something new folks can expect to learn this week?

Jennie: While the term DevOps has been around for a while, it’s still convoluted to many. What I’m excited about for this week is that we’ve brought in so many DevOps experts across GitHub to share the lessons, strategies, and best practices we learned from working with our customers. The four sessions this week will cover not only the DevOps fundamentals, but also motivations for change, trends in the industry, and how to get started on a transformational journey.

We’re looking at what’s new for DevOps today, but also what’s next. In this week’s fireside chat we’ll be answering some tough questions, including whether we’ve reached the limit of what DevOps can do. Give us a hint—have we?

Jennie: DevOps encompasses tooling, development, operations, automation, culture, and most importantly, it’s a methodology that brings them all together. DevOps has turned them into something that’s greater than the sum of their parts for more than a decade now. Have we reached the limit of all that?

What’s more, we still have to consider:

• 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

We’ll be covering all the above during DevOps Week, especially in our Breaking down DevOps conversation with Bryan Liles from VMware.

Developer Experience Week showed us why thinking ‘developer-first’ can help your team and your organization. How does being developer-first apply to DevOps?

Daniel: With the advent of DevOps, a lot of specialist groups are shrinking and the burden is shifting more and more upon the developer to deliver better software, faster. One example is security. Security is becoming more of a developer responsibility as opposed to something applied later in the software development lifecycle. Finding vulnerabilities at development time is critical for several reasons, but security researchers are rare and expensive. So, how can we share their work among all software development organizations?

Fortunately the answer is there right in front of us—DevOps! Along with making sure code passes functional, performance, and integration tests, we can focus on code quality. From a developer-first perspective, a vulnerability in many cases is simply a code quality issue that can be exploited by a bad actor. Next week, we’ll walk through how to bring rapid code quality feedback into the branch, commit, and pull request cycle in a way that matches test result feedback, so developers aren’t seen as the cause of a security problem. It just becomes another test result to address and fix. Even better, when that feedback isn’t security-speak but in developer-speak, it’s far easier to digest and make required changes. Other developers dropping by can see that instant feedback and learn as well, so everyone learns together instead of one person being singled out for making a mistake.

Along with security, innersource also brings something new into the DevOps equation. What is innersource, and why are we including it in DevOps Week?

Daniel: Every company is now competing for the same developer resources at a global level. In fact, we see traditional organizations leading developer hiring compared to their digital-first competitors. Large organizations are learning how to do more with the same or fewer resources, while balancing changes to distributed teams and remote work. Open source has been a big help with that. Organizations can open source code that isn’t critical to their business or their intellectual property. But what about getting faster with the code they do need to write?

Open source solves more than code resourcing issues. Open source communities have had to deal with scarce and distributed developer resources for years. They’ve solved this through shared discovery of code and process, automating testing, providing direct and rapid feedback and, finally, an open and supportive culture—the kinds of things DevOps practitioners strive to provide. Innersource is the process of taking these lessons learned from the open source community and applying them internally within your organization. At InFocus, you’ll learn how to set up your own innersource program, why innersource is an important factor in DevOps, and how it creates a positive feedback loop by bringing the philosophies and solutions of the open source community back into DevOps.

Next week we’re hearing from teams at Skyscanner and Otto Group on their unique approach to DevOps. While there are some shared principles, everyone does DevOps differently—and it sounds like that’s a good thing. Can you tell us more/why?

Marko: Every organization is unique, with unique processes, challenges, and goals. If you’re just starting out, you may be more focused on experimentation versus finding new ways to automate established processes or build on the tools you’ve already invested in. A large organization that’s been doing security and compliance for years operates differently from a startup. Both may share the same overall goal—building and shipping great customer experiences—but the way they get there doesn’t look the same. Why should it? There are DevOps best practices we can all learn from each other, but staying competitive means focusing and improving the processes that are unique to your business and team. With Skyscanner and Otto Group, you’ll see two different organizations with successful DevOps programs, how they define success, and how they got there.

There are a lot of processes beyond CI/CD that have the potential for automation, like in DevSecOps. What are some examples that teams can expect to see at InFocus?

Marko: Automating CI/CD is just one part of DevOps. Like we saw at Developer Experience Week, there are so many other parts of your software lifecycle you can simplify, whether it’s compliance checks or managing team notifications. Again, it’s all about identifying where your team spends the most time. If your developers are spending more time fixing vulnerabilities than writing code, there are ways to automate that process. If developers are being pulled away to track down Jira tickets or update their work status, GitHub Actions and other integrations make it possible to comment on Jira from within pull requests. These are just some examples, but we’ll be walking through how to automate and manage every part of your DevOps process from one platform.

If folks could only take away one thing from DevOps Week, what should it be?

Jennie: Tools and platforms are fundamental to DevOps because they influence the way your team works, and in time the way your team works shapes your culture, which can ultimately become your biggest competitive advantage. I’m looking forward to hearing from the speakers on all the ways we can help to power a successful DevOps program.

Daniel: In the DevOps world, developer-first doesn’t mean developer-only. Everything we can do to help remove blocks and bottlenecks to help developers turn out better code faster is a win for all. It makes operations easier, it makes security easier, it makes feedback easier, and it makes customer success easier.

Marko: If you’re waiting to try DevOps or bring in more automation, there may never be a “perfect” time. Change creates friction, but it’s important to try new things and give your team space and time to find their way. Listen to developers, continuously gather feedback, and you’ll find the balance between efficiency and trust.

Want to learn more? Tune in to DevOps Week at InFocus starting on March 2 at 9am PT / 12pm ET or check out the full list of sessions.

Written by

Grace Madlinger

@gmadlinger