GitHub Actions vs Azure DevOps: A Quick Guide to Microsoft's New CI/CD Platform
At Microsoft Build 2020, the direction that Microsoft is moving was apparent. Many of the sessions about deployments and Continuous Integration/Continuous Delivery (CICD) centered around GitHub Actions CICD. With Microsoft’s acquisition of GitHub in 2018, it only makes sense to start cashing into GitHub Actions.
GitHub Actions is the newest CICD platform in the DevOps family of tooling. What makes GitHub Actions so unique is that GitHub itself is arguably the most popular distributed source control repository in the world. As of January 2020, it has over 100 million repositories. That means developers don’t have to leave Github anymore and sign into a CICD platform. Instead, it’s all in the same place — a centralized location, so to speak.
In this blog post, we’re going to look at five key differentiators between GitHub Actions and Azure DevOps.
GitHub Only for GitHub Actions
With Azure DevOps, you have the ability to work with pretty much any distributed source control system you prefer. You can tie in code from GitHub, Azure Repos, GitLab — whatever you want to use. This truly provides an end-all-be-all DevOps solution because you aren’t locked into one source control repository. You can use whatever you are comfortable with depending on where the code is.
At the time of this writing, it’s unclear if GitHub Actions will be usable with other source control systems. Currently, to use GitHub Actions, you are locked into using GitHub. For most people and organizations, this is okay because their code is in GitHub anyways. However, with the increasing demand for non-vendor lock-in, there is a chance this might deter some developers.
No Deployment UI in GitHub Actions
During the past year or so, Microsoft has made it clear for both Azure DevOps and GitHub Actions, they are moving in the direction of YAML pipelines. YAML pipelines provide a way to define a CICD pipeline as code. That means no more clicking around a UI or accidentally clicking the wrong button. Instead, you can write the pipeline in code, store it in source control, and ensure your team can review it for better visibility.
Most of Microsoft’s documentation for Azure DevOps currently defaults to using YAML pipelines. In fact, they call the UI version of creating a CICD pipeline the classic version. While Microsoft is moving in the direction of YAML pipelines, Azure DevOps still has the ability to use classic pipelines. Depending on the needs of an organization, classic may be better.
For example, YAML pipelines don’t support deployment groups, which is a grouping of virtual machines for deploying applications. If an organization is still deploying applications to virtual machines, YAML pipelines may not be the best solution for them.
With GitHub Actions, you only have one option, and that’s YAML pipelines. It makes sense because YAML pipelines are the future — and why build old onto new? However, this can be a problem for some developers or organizations depending on their workflow.
Better Security in GitHub Actions
Static code analysis is the practice of scanning code while it’s in a repository, or even open on a machine. There are platforms that specialize in code analysis as well, like Sonarqube. With static code analysis, you have the ability to automatically scan code for things like Kills, bugs, syntax issues, and library issues.
At Microsoft Build 2020, code scanning was introduced. This was one of the crowd’s favorite implementations. Code scanning is essentially security a static code analysis in GitHub. Most security issues with code in source control typically are:
- API keys that shouldn’t be public.
- Passwords being stored in code.
- Keys and key/value pairs that shouldn’t be public.
With an implementation like security static code analysis, this will definitely put GitHub Actions as a front runner from a security perspective. Although Azure DevOps has security features built into the pipelines, it doesn’t have any security features like code scanning built into Azure Repos.
Codespaces in GitHub for GitHub Actions Deployments
One of the other huge announcements at Build 2020 was Visual Studio Codespaces. Codespaces is an online version Visual Studio Code. You don’t have to worry about downloading Visual Studio Code, adding extensions, and setting themes. Instead, you can have an online version of Visual Studio that is built and deployed in Azure.
With the popularity of Codespaces, Microsoft kicked it up a notch and announced that Codespaces would be built into GitHub as well. Microsoft is truly building a centralized place for development. With GitHub Actions, you can now store code in GitHub and deploy it. Now, you can write code in GitHub, store it in GitHub, and deploy it from GitHub. Why would a developer want to leave GitHub with a stack like that?
Where the Code Runs
The way code runs in pipelines is from a container, a machine, or some sort of virtual environment. When you run a pipeline, it gets run somewhere. That somewhere will depend on how you set up agents. In Azure DevOps, pipelines use agents. There are a few different types of agents:
- Windows-Hosted Agents. Microsoft maintains and does all of the care and feeding of these environments. These are typically containers running in the background.
- Self-Hosted Agents. You can self-host an agent running on a Windows 10 laptop that handles all of the deployments.
- Docker Agents. Deployments with a pipeline can be made from a Docker container. Once the agent is installed and configured, the pipelines can run.
GitHub Actions, however, uses an assigned virtual environment. The virtual machines are GitHub-hosted environments, so you don’t have to worry about any maintenance. Virtual/GitHub hosted environments come in three flavors:
You can also create your own self-hosted virtual machine — very much like Azure DevOps.
You now know some of the key differentiators between GitHub Actions CICD and Azure DevOps. It’s not set in stone, but from what was seen at Microsoft Build, many of the new features are going to GitHub Actions CICD — and not Azure DevOps. Our recommendation would be to not abandon Azure DevOps all-together. But definitely start paying attention to GitHub Actions CICD.