An approach to Git integration in Issue Tracking Systems.
its-g is supposed to be used by software teams to track and associate bugs that arise during development with github commits across branches. It aims to be a simplified alternative the increasingly complex flow of feature-heavy modern tools like Jira, Clickup etc. The app has the essential feature of multi-teams and access controls while also having a simple bug report and update flow. This ensures that a small team of 2-10 can go up and running in a couple of minutes without having to read documentation or learning about different buttons.
The app makes use of fine-grained personal access tokens of a repository (that only requires read access to read the latest commits acorss branches).
Reporting a bug has the option to choose a commit at which the bug was enountered. This is supposed to be the latest commit of any branch. While closing the bug, we can also specify at which commit the bug no longer exists.
It builds on the idea that a bug/issue is generally linkable to a commit(s).
So, while reporting a bug, it may have been present from previous several commits, but it would definitely be present on current commit. Hence, if we tie that bug report with this current commit, which establishes that the problem was there till at-least this commit.
The use-cases can be
- A developer encounters a bug, reports that issue with current commit of that branch. Another developer decides to investigate later and finds that it is no longer there without solving, so they can checkout to that commit which gaurantees that bug. This helps to mitigate unintended changes in the codebase or better understand the problem.
- An year later, another developer is working and encounters the same bug in their code, they can refer to this bug's closing commit (not implemented yet) to see what made the bug solvable
- The opening and closing commit of a bug/issue create a definite closed range in which the bug was present and solved.
- A developer is working on a branch/main
- They encounter a bug or want to create an issue.
- Create a bug/issue on the project dashboard
- If they have enabled git integration, they would be presented with the names of all branches and latest commit's hash.
- Select the desired branch and add that commit.
- Close commit is not yet implemented
- A user can create a project of their own or join other user's projects
- Git integration is opt i via fine-grained PAT withe read access. It can be changed later on too.
- Project admins can grant or revoke manager-level access to members as well as remove them from the project.
- A comment and update stream is created for each bug to ensure that all updates are recorded in history.
- The bugs are assignable, and their priority can be changed.
- Status of a bug can be changed as the fixing progresses.
- Invites can be sent to users while creating the project or later on. Similarly, invites can be recieved and accepted/rejected.
- Members and Commits can be managed at the project dashboard through dropdown panels.
During my SWE internship, I discovered that a lot of bugs that dev teams encounter are already solved some time earlier in the same project too. My reading habit then took me to these recently introduced fine-grained access tokens by Github and came up the idea to do this project. These tokens allow repo restricted access.
This app is supposed to benefit internal issue tracking more than quality analysis round as the inspiration and approach is to benefit developers in avoiding repetitive bugs.
Nodejs, Expressjs, Reactjs, Mongodb, Shadcn-ui, Tailwind
Vercel, Railway, Mongodb Atlas
To showcase correctly its working, I created three accounts as sample. I am yet to make these specific ones as readable only and hence they can be edited. Plus, as people will inspect the app, the database may cross paid threshold. For these reasons, I have employed a MongoDb Atlas Trigger to restore to my desired dataset.