Sep 27, 2021 by Troy Walsh
GitHub As Your Primary DevOps Toolchain
What you need to know before selecting GitHub as your primary DevOps toolchain.
What is GitHub?
For those of you not familiar, GitHub started off as an online source control management service. Over the years it has become the world’s largest source code hosting service and has been used by more than 50 million developers. It hosts many of the most popular software projects such as Kubernetes, .Net Core, Go, TypeScript, Apple Swift, Node.js, Apache Spark and many many more. In 2018 Microsoft acquired GitHub and over the last couple of years has done a lot of work expanding GitHub’s capabilities and feature sets.
Security and access control management within GitHub is very sound. Access within an organization can be managed by individuals and/or by “Teams”. Public repositories allow you to control what level of access non-member have. If you chose, GitHub will also automatically scan your code for vulnerabilities. On top of this things like2 factor authentication are freely available to all projects. Some of the more corporate IT type things such as SSO and LDAP support are available as part of the GitHub enterprise tier.
Source Control Management
You would be hard pressed to find a better option. GitHub is considered by many the top source control management service in the world. It has been doing its thing for well over a decade and hosts over 500M repository.
GitHub has rudimentary/lightweight project management capabilities. Units of work are called “Issues.” GitHub Issues are roughly equivalent to issues in Jira or work items in Azure DevOps. The difference is that issues are categorized based on tags rather than types. This is nice in that you can have an issue categorized as both a feature and a bug for example. The obvious downside is that issue can be difficult to manage as they can have multiple (or no) tags at all.
GitHub has two other important capabilities in this space. They have “Projects” which are basically Kanban boards for issues or project notes. This can be somewhat confusing as project notes are not “Issues” but can be converted to them. The other capability is “Milestones”. Milestones are typically used to group work for a release, feature, and/or period of time. These are roughly equivalent to iterations, sprints or epics in Azure DevOps or phases, sprints or epics in Jira.
From a reporting perspective GitHub is very limited. There is currently nothing like Azure DevOps or Jira dashboards. Furthermore, there are no built-in capabilities for capacity planning, test management, or anything of that sort. There are some third part extension which can be used to get pieces, but nothing looks good or integrates that well.
The build/release feature in GitHub is called “Actions.” Actions are YAML base pipelines. They are very very similar to the YAML based pipelines in Azure DevOps and Bitbucket Cloud. These pipelines can also be leverage to automated project processes such as the closing of stale pull requests or deleting old branches. By default, Actions jobs run on the same cloud agent as those used by Azure DevOps. Teams can also setup and use their own build agents if the hosted agents don’t suite their needs.
Actions do have some pretty notable limitations. First, you better like YAML based pipelines because that is your only option. Second, YAML templates basically only support run (batch, bash, PowerShell, etc.) commands. Third, extension options can be a bit hit and miss. Fourth, secrets management and service connections are is very primitive; you don’t get anything like Azure DevOps variable groups and service connections. Finally, release gates are largely unsupported. For the most part this is likely not a deal breaker for most projects, but the are limitations that are good to know.
Is It Good Enough?
It could be argued that GitHub is good enough for most software projects and ideally suited for most open source projects. The core feature set is solid and easy to work with. The project management and CI/CD systems are more limited then say Jira, Azure DevOps, or Jenkins. That being said, the feature set present in GitHub is more than sufficient for most projects.
*One key thing to keep in mind is that GitHub can integrate very tightly with Azure DevOps. This means you can start a project just using GitHub and if you find you need the richer feature set you can integrate your GitHub project with Azure DevOps.