The code review chaos we faced with GitLab (and what we tried to fix it)

I've worked in several agile teams as both a developer and lead developer. One particular project sticks in my mind — a team of ten people, dozens of microservices, and a lot of GitLab repositories to manage. During each sprint, we were juggling features across multiple repos. At the same time, we were responsible for reviewing each other’s code. Our typical flow was: Open a merge request (MR) on GitLab Move the related Jira ticket Share the MR link in a Teams channel Move on to the next story When the workload was light, it was manageable. But in busy sprints, reviews piled up quickly. Large MRs got ignored, or rushed through. And tracking what was waiting, what was blocked, or what still needed input? A mess. What we tried We experimented with several ideas: Using GitLab labels like needs-review or blocked Adding Jira tags Rotating reviewer ownership by repo each sprint They helped — but they didn’t solve the root problem: lack of visibility and timing. Code reviews were often asynchronous and scattered. We were switching contexts constantly, jumping between repos, and forgetting which contributions needed our attention. What we realized We didn’t need more tools — we needed a better way to surface and track reviews. Something that would: Give us a unified view of MRs Let us know what’s ready to merge, what’s waiting, and what’s blocked Respect our flow, instead of interrupting it That’s when I started working on a side project, aiming to solve this specific pain point. What came next That side project became Bellugo — a contribution tracker designed to help teams stay on top of reviews across repositories without the chaos. It’s still a work in progress, but if this resonates with your team, I’d love for you to check out the landing page and maybe join the private beta waitlist.

May 6, 2025 - 01:35

The code review chaos we faced with GitLab (and what we tried to fix it)

I've worked in several agile teams as both a developer and lead developer. One particular project sticks in my mind — a team of ten people, dozens of microservices, and a lot of GitLab repositories to manage.

During each sprint, we were juggling features across multiple repos. At the same time, we were responsible for reviewing each other’s code. Our typical flow was:

Open a merge request (MR) on GitLab
Move the related Jira ticket
Share the MR link in a Teams channel
Move on to the next story

When the workload was light, it was manageable. But in busy sprints, reviews piled up quickly. Large MRs got ignored, or rushed through. And tracking what was waiting, what was blocked, or what still needed input? A mess.

What we tried

We experimented with several ideas:

Using GitLab labels like needs-review or blocked
Adding Jira tags
Rotating reviewer ownership by repo each sprint

They helped — but they didn’t solve the root problem: lack of visibility and timing.

Code reviews were often asynchronous and scattered. We were switching contexts constantly, jumping between repos, and forgetting which contributions needed our attention.

What we realized

We didn’t need more tools — we needed a better way to surface and track reviews. Something that would:

Give us a unified view of MRs
Let us know what’s ready to merge, what’s waiting, and what’s blocked
Respect our flow, instead of interrupting it

That’s when I started working on a side project, aiming to solve this specific pain point.

What came next

That side project became Bellugo — a contribution tracker designed to help teams stay on top of reviews across repositories without the chaos.

It’s still a work in progress, but if this resonates with your team, I’d love for you to check out the landing page and maybe join the private beta waitlist.