09 May 2023
If you work at a Microsoft-oriented corporation that leverages Azure’s public cloud heavily, you might be using Azure DevOps for version-controlling source code repositories with Git and for automating build / test / deploy processes against those codebases.
Do you wonder if you’re missing out by using Azure DevOps instead of GitHub?
Below are some strengths of each tool. I’d love to hear your additions in the comments.
Azure DevOps strengths
- In a Microsoft-oriented corporation…
- …Azure DevOps Boards might already be the Kanban board project management tool of choice for developers and nondevelopers alike, meaning people might be more likely to already have Azure DevOps open in their web browser all day.
- …Web browsers, including those built into mobile phones and tablets, tend to stay signed in (single sign-on, a.k.a. “SSO”) and multifactor authenticated (“MFA”) into Azure DevOps better than they stay signed into GitHub.
- …There might be a bigger internal community of on-staff developers who are accustomed to using Azure DevOps Repos and Azure DevOps Pipelines.
- …Azure DevOps might be about 3-4x cheaper per developer? Especially once you add in the marginal cost that you’re potentially already paying for Azure DevOps accounts for developers anyway if ADO Boards is your company’s Kanban board of choice.
- …Despite GitHub’s better industry-wide name recognition, the Microsoft-maintained set of “tasks” available to Azure DevOps Pipelines doesn’t seem to lack any of the basic functionality offered by the Microsoft-maintained set of “actions” available to GitHub Actions. (“If it ain’t broke, don’t fix it.”) If there is already inertia in a corporation for Azure DevOps, many developers may feel that ADO hasn’t presented any shortcomings that necessitate migrating to a new tool.
- Azure DevOps Pipelines offers a beginner-friendly point-and-click GUI for building CI/CD pipeline automations in addition to its YAML-based offering, where as GitHub Actions only has a YAML-based offering. (Some teams might see this as a disadvantage.)
- Azure DevOps Pipelines seems to offer more seamless integration into logging the results of automated test execution into the “runs” history panel of Azure DevOps Test Plans than GitHub Actions offers, which Quality Assurance teams might appreciate.
- Azure DevOps seems to offer more granular control over repository view+edit permissions and CI/CD pipeline view+edit+execute permissions and stored-secret edit+execute permission than GitHub offers. (Some teams might see this as a disadvantage, as “more control” can mean “more nuisance buttons to remember how to click correctly.”)
- Some developers I spoke to felt that GitHub Actions runtimes spin up faster than Azure DevOps Pipeline runtimes.
- Developers I spoke to who had used both tools felt that GitHub Actions offers just as seamless of integration into Azure DevOps Boards as Azure DevOps Pipelines offers, meaning they don’t find GitHub too “in the way” of integrating automations with project management Kanban board work.
- Some developers I spoke to felt that GitHub Actions’s forced use of YAML (its lack of a GUI-based CI/CD pipeline) is a strength. They’re strong believers that definitions of CI/CD pipeline automations should always be stored as files inside the repository of which they automate the building / testing / deployment.
- Some developers, particularly on small teams where “everybody does everything anyway,” prefer the shallower learning curve and simplicity of GitHub’s less-granular access control.
- GitHub itself comes with a lot better static scanning for package versions, accidental secrets stored inside of repositories, etc. (Dependabot, etc.)
- GitHub comes with the github.dev web-based code editor, which lets you edit multiple files at a time before committing a change.
- (Azure DevOps’s built-in file editor makes you commit each file you’ve edited, one at a time.)
- GitHub can come with Codespaces.
- If your company allows you to use it, GitHub can come with Copilot.
- Some developers prefer the suite of plugins and integrations available to the VSCode and Visual Studio local desktop integrated development environments (“IDEs”) for GitHub vs. Azure DevOps.
- For example, they love some plugins’ auto-synchronization of stored secrets.
- Some developers feel that, both due to GitHub’s user interface and due to GitHub’s widespread popularity (and hence Googleability / coverage in blogs and StackOverflow, etc.), it can feel easier to discover features and best practices availble in GitHub than to discover the equivalents in Azure DevOps.
- For example, although Azure DevOps Pipelines lets you store secrets in a setting called “variables” that is very similar to GitHub repository/actions “secrets,” some developers I spoke to had never noticed it and didn’t know it was an option in Azure DevOps.
- As another example, some developers found the learning curve to build inter-YAML-file dependencies into GitHub Actions easier than they found it in Azure DevOps Pipelines.
- As another example, some developers felt more comfortable figuring out how to make a given GitHub Action “target multiple environments” (e.g. a lower nonproduction environment, then a higher nonproduction environment, then a production environment) than they felt figuring out how to achieve the same goal in Azure DevOps Pipelines.
- (On the other hand, other developers I talked to who exclusively used Azure DevOps, due to never having been given significant access to use GitHub Actions, felt very comfortable doing so in Azure DevOps Pipelines.)
- Similarly, because no credit card is required to open a GitHub account and host sample code publicly, whereas Azure typically requires a credit card, the general public has generated a lot more content about how to achieve various CI/CD automation goals in GitHub Actions than in Azure DevOps pipelines. It may be a longer Google hunt to find the way to solve a problem in Azure DevOps Pipelines than in GitHub Actions, even if Azure DevOps Pipelines offers the exact same functionality as GitHub Actions.
- Continuing this theme … some developers are simply accustomed to GitHub and feel more comfortable in it due to their deep experience in it from weekend hobby projects, work at previous companies, etc.
- Some developers felt that GitHub’s website had a much better user interface than Azure DevOps’s website for resolving codebase conflicts in pull requests.
- (In Azure DevOps, the developers I spoke to felt that you have to add a marketplace extension to your local desktop IDE to upgrade your UI for resolving pull request conflicts.)
- GitHub allows more granular scoping of key names in key-value pairs than ADO. GitHub’s smallest namespacing of key-value pairs is “Environment,” which adds a level of key namespacing to a given repository. ADO’s is “Variable Group,” which adds a level of key namespacing to an entire ADO project (multiple repos can exist per project). GitHub’s choice lets you feel tidy with slightly shorter namespace names.
- (Note: A developer I spoke to guessed that ADO’s weird practice of making “variable groups” and “pipelines” project-wide siblings to repositories, rather than children of repositories, might have something to do with ADO having roots in the TFS source control protocol, whereas GitHub was developed specifically with the Git source control protocol in mind.)