How well maintained are your Git management processes?
Technology organizations today more or less have moved to Git as a tool for source control. Along with Git comes your favorite issue management tool like Gitlab, GitHub, Jira, etc. While all developers have guidelines from their organization for Git related process, how do we reconfirm that they are being religiously followed? Let me explain with a few use cases.
Few commonly followed standards:
1. A bug raised should have environment (uat/prod/dev) tag along with severity (critical/high/med/low) tag.
2. Do all issues / tasks have a time estimate and a time spent tagged (how much do the difference varies by? to indicate that they are meaningful entries)
3. What was the state of the issue before being marked as closed. Was it closed because it was ignored by a developer or just to get off the active dashboard?
Open issues / tasks popup daily on the developers / managers desk but if closed does one really check if the maintenance has been done correctly?
Stale Git branches
Standards define to create git branches for every change request (enhancement / bug / etc.). Multiple change requests are added and removed in uat for which we have merged branch for testing purposes. How many such stale merged branches exists where developments have been scrapped and/or no longer valid? Remember, your organization is paying for the extra storage.
Protected Branches
Your Git administrators have changed overtime, new projects / milestones are being created. You have set a standard condition to mark certain branches as protected. How do you assure that this process is being followed?
Missed Mapping
Do you have a policy to tag issues to a milestone? Has your newly joined developer / manager have missed it? How do you know, if the issue has been closed
Missed default issues in milestones
In another scenario, suppose there is a mandate under every milestone to create one issue with documentation tag and another with testcase tag which will have respective data. Has the concerned person followed that protocol?
Closure dates
Do all issues / milestones, etc. have closure dates
Commit Messages
Does your team commit without proper (none / too short) commit messages. Your system records but do you have a summary of such history?
One could think of many such scenarios. We presume that we follow standards, but isn’t this based on manual human checks? Shouldn’t organizations be implementing automated systems in place to verify human errors?
The first step is to download your git & issue management data into a repository which can be easily queried. https://github.com/godwinpinto/gitlab-etl is one such open source tool that can help you download your organizations git & Gitlab information into a mongodb database. Further you can use any BI / reporting tool to fetch the data points from mongodb and outline such standardization gaps for review.
We all agree that Git and issue management tools are the assets of any company dealing in software development business. Shouldn’t the data health and sanity be our priority too?
