This post is part two in a series discussing challenges we faced managing VMware GitHub organization and improving open source operations. Read part one here.
Over the past year, GitHub started to gain popularity internally with our engineers and began to see more usage, but without active administration, things were quickly becoming a mess. We had over 500 members in the VMware GitHub organization, but could only identify about half of them. We had hundreds of teams that either had no members, were mapped to no repositories or provided redundant read permissions that matched the default organization permission level.
We also had not migrated to the improved organization permissions, which could have left the door open for organization members to freely create public repositories and release code without going through the proper open source approval channels.
After discussion with a few other VMware engineers actively using GitHub, we came up with a set of simple ground rules that we would use to do the initial clean up:
1. No admin or read teams
2. No external collaborators with admin permissions
3. All VMware employees interested in working in the VMware organization must be organization members, and not external collaborators
4. When a VMware employee leaves the company, they must be removed from the organization
5. Each repository must have one team with write permissions
6. Each team must have a maintainer to manage membership
7. Teams that are not mapped to any repositories should be deleted
The effort began as a set of scripts using the GitHub API, but quickly evolved into an internal web application we call GitHub Manager.
This tool streamlines a number of actions:
1. When a user wants to join any VMwar GitHub organization, there is a self-service process for linking your VMware LDAP account to your GitHub account using OAuth and getting an invite sent. The same process is followed for automation/bot accounts.
2. Query LDAP on a set schedule to look for organization members who are no longer VMware employees and do the appropriate cleanup.
3. Provide search functionality to lookup users based off VMware LDAP or GitHub login.
4. Allow project maintainers (member of a team with write permissions to a repository) to obtain temporary admin permissions on their repository for configuration changes.
5. Provide workflow for creating and releasing new open source projects on GitHub. This workflow integrates with our internal open source process portal to make sure proper approval has been obtained prior to project release.
6. GitHub data collection – Future blog post topic? 🙂
GitHub Manager will continue to evolve as GitHub adds more features intended for business. We are keeping a close eye on the recently released SAML SSO integration and support options and any future enhancements.
Shout out to the GitHub support team, especially Ivan Žužak. We reached out to their team a number of times with API queries and were always met with timely and helpful responses. New feature suggestions were always well received and even implemented in certain cases.
