Project Management with GitHub
GitHub’s project management capabilities: The good, the bad, and the interesting
By Troy Walsh, QE Practice Lead and a Lead DevOps engineer, Cognizant Softvision
In this post we will look at the current GitHub project management capabilities. As I mentioned in a previous post (https://bugsareinthegaps.azurewebsites.net/github-as-your-primary-devops-toolchain) GitHub has some decent, but limited project management capabilities.
The Good
Source Control
GitHub started out as a source control management service and it shows. Creating forks, branches and pull requests can all easily be done thought the GitHub browser portal. However, you are not limited to the browser interface. There is the GitHub CLI, GitHub Desktop, and/or IDE integrations. Pretty much any modern IDE has robust GitHub integration. In the case of Visual Studio, the integration is virtually seamless.
GitHub also has an intuitive pull request interface which make it easy for requesters and reviews to collaborate. Is also make it very clear exactly what code is being touched.
On top of all that GitHub makes resolving basic conflicts very simple.
*This works best for simple merge conflict.
Security
GitHub has some really solid security features, even on the free tier.
Basic user access is pretty simple. Users can be managed on the organization and individual project level. Teams can also be used to group user together, so you can manage their access as a group. Members and/or teams are assigned different roles within different projects which dictate what access they have.
In addition to explicit user management GitHub also allows project to define what outside collaborators can do; this is especially important for open source projects.
There are several built-in security features which help project find issues and keep third party references up to date. The built-in security scans can find refence with known security problems. The Dependency graph make it easy to see what libraries you depend on. Last but by no means least; Dependabot can find automatically create PRs for outdated and/or vulnerable dependencies.
*If you are using GitHub but not Dependabot, you’re doing something very wrong!
In cases where an organization requires more advance access feature such as SSO and LDAP they will need Enterprise licensees.
Notifications
GitHub gives you a lot of control over notifications. For example, you can have different notification email addresses for different project. The also provide a convenient notification hub where you can see all your notifications in one spot.
Basic Planning
Issues are what GitHub primarily uses to track work. Issues are roughly equivalent to work items in Azure DevOps or issue in Jira. Unlike Azure DevOps and Jira issues don’t have types be rather issues can have zero or more labels associated with them. As you can image this can be good when you keep thing simple and can be a management nightmare if you try to get too complex.
Inside GitHub issues are often managed by the issue list, projects, and/or milestones. Project are basically Kanban boards that can have a mix of issues and project notes. This can become a little confusing as notes can be converted into issues after the fact. Milestones on the other hand are roughly equivalent to iterations, sprints, or epics in Azure DevOps or phases, sprints, or epics in Jira. Milestones will often have a due dates associated with them. It is not uncommon to use both projects and milestones in conjunction with one another.
The Bad
Planning
If you are looking to do more than basic Kanban, you will likely need more than just GitHub.
Reporting
Reporting is virtually non-existing in GitHub. You can get things like badges but that is about the extent of the built-in reporting capabilities.
Bug Tracking
There is really no bug tracking to speak of. Bugs are just issues with the bug label.
I must admit, I think this is generally a good thing. Work is work no matter what you call it.
Test Management
GitHub has no test management. This works fine when you are dealing with things like unit tests but once you start dealing with higher level testing it gets more complicated.
The Interesting
Discussions
Discussions can be a convenient way to get project feedback. It can also be used to show off new features and/or answering common questions. This also helps keep project from getting a bunch of issues that are just questions or requests.
Insights
Insights provide just that, insight into a project. You get a good high-level view of the project activities. You can see contributes, dependencies, forks and more.
Readme, Wikis and Pages
GitHub provides teams with multiple ways of documenting projects. By default, the contents of a project’s readme file is displayed on the front page of the project site. This is a good way of providing a 10,000-foot view of the project. There is also a wiki available, but I personally find that to be kind of a pain to work with. My preference for documentation is GitHub Pages. GitHub Pages will actually create a documentation site for you. Pages sites are largely Jekyll based which makes them pretty easy to update and tweak. The other big benefit of Pages is that your documentation livers alongside your product code.
Forks
At some point you may find you want a copy of another repository. This may be because you want to make a change to a project but are not part of the project team or you want to fork an abandoned repository, or you want to take the project in different direction, or some other reason. Whatever your reason may be; GitHub makes Forking public repositories dead simple, just two clicks and you can fork pretty much any public repository.
Azure DevOps Integration
GitHub’s limited ALM features set will not cut it for every project. The nice thing with GitHub is that if you decide later that you need the richer feature set you can always setup the Azure DevOps integration. The integration isn’t perfect but really good in comparison to other such integrations.
For more information see: https://docs.microsoft.com/en-us/azure/devops/boards/github/?toc=%2Fazure%2Fdevops%2Fboards%2Ftoc.json&view=azure-devops
Conclusion
GitHub is not as feature rich as most traditional ALM tools and that is both its strength and weakness. Smaller projects can get up and running very quickly with very little effort. Many larger teams will find the feature set limiting, especially from the management and reporting perspectives. My general view is that GitHub is a great place to start a project and if you find you need more enterprise level features later on you can always take advantage of the Azure DevOps integrations.
Get more insights from our engineering and design experts on our website!
