Swapnil Bhartiya, CEO and Host at TFiR, interviewed Chris Patterson, Product Manager from GitHub Actions, for TFiR Insights to discuss how the company is approaching DevOps and about the recent DevOps and GitHub Actions announcement.

Who is Chriss Patterson?

Mr. Patterson is the lead product manager for GitHub Actions, and focuses on the end-to-end experience for GitHub’s actions, extensibility model, and overall developer experience. He’s been working with such technologies for about 15 years, so he has the background and experience to speak to the DevOps space.

What is GitHub Actions?

For those that don’t know, GitHub Actions is commonly used for Continuous Integration (CI). However, GitHub wanted to focus beyond the simple CI workflow and into automation. They found people wanted to automate things like comments, pull requests, linting, scanning, and security. To that end GitHub Actions is about providing developers with the platform to automate the things they do inside of GitHub, and (in some cases) things they do outside of GitHub. Another part of what Mr. Patterson does is to see how imaginatively users work with GitHub Actions.

How do developers use actions?

According to Patterson, GitHub has found developers are using actions for a variety of tasks. One of the most common use cases lies outside of the CI workflow—triage bots. With these automated bots, developers automate actions such as when pull requests come in, requiring decisions that could be more easily (and efficiently) handled by a bot. For example, does a pull request have all of the necessary information required or is it the first time a developer has opened a pull request? If a triage bot detects this is a first-time pull request, it can automatically send them a special reading or additional information about how to contribute to the project. To that, Patterson says, “…automating that has definitely been a big deal for a lot of our sort of larger open source projects.” He continues, “The Enterprise customers I’ve talked to…a lot of them are about getting fewer tools, frankly, in their toolbox, or at least more tightly integrated, less different things to maintain.” Finally, Patterson adds, “And the introduction of GitHub Actions has really allowed them to potentially retire some of their other infrastructures, and bring those CI workflows closer to the developer…”

At its core, GitHub Actions is a configureless code model, stored in your GitHub repo. As you declare, your workflows are built into that model. GitHub Actions is working very closely with the community on their plans to further extend actions and figure out whether it fits directly with Flux or another GitOps operator.

Patterson also addressed the announcements regarding GitHub Universe. Their goal is to help customers build Continuous Delivery workflows. One thing they’ve discovered is there are things missing, such as the ability to have some sort of approval mechanism before an app or service is deployed to production. To resolve that issue, GitHub Actions bult several different features that work together to help developers build secure Continuous Delivery pipelines. Users of GitHub Actions can work with that feature for free. With this tool, you can see every time a developer deploys to production and insight into the exact workflow run for that particular deployment.

As to the role CD will play with integration, Patterson says, “I think that we’re gonna see…security continue to become more and more important, and some of the stuff we saw towards the end of last year, bring that up, you know, there was this particular vulnerability that somebody got onto somebody’s CI server and injected malware into this network management product, right.”  To avoid such an eventuality, GitHub offers (with their advanced security product), code scanning, qL language (for deep analysis into potential security problems), and secret scanning dependency graphs.

Finally, as to DevOps and SRS trends, Patterson says, “the ability to operate is different than the ability to develop. But I think that both of those two worlds have to continue to better understand what each other does and what the core needs are for those two different sides of the business and work more closely together.” As to GitHubs role in this, Patterson says, “…the more that we can keep things centered around the code, and whether it’s the operational side of the code or the development side of the code, I think we can continue to help lighten the load.” He ends by saying, “…community aspect of GitHub is, you know, obviously been there for a very long time. And…we continue to expand the ways in which the community can help each other.”

The summary of the show is written by Jack Wallen