Your merge request
Your quality gate
Don’t Merge Until it’s Clean
Merge requests are an explicit step in your development process, which helps to make everyone aware of the quality expectations and even enforce acceptance rules.
Teamscale integrates with the merge requests (or pull requests) in GitLab, GitHub, BitBucker and Azure DevOps, ensuring that both you and your reviewer get the information you need to do your work right where you do your work.
Teamscale may insert a findings badge into your merge request, to show you new, remaining and resolved findings, vote on your request or even add detailed line comments, just like a human reviewer would.
Put it to Use
Set the quality-bar high for changes to be admitted into your main line, to prevent technical debt from creeping in, which would come back haunting you later. There’s no better time to clean up than now, when you fully comprehend the code, because your just changing it!
Sometimes you deviate from standards and guidelines for a reason. Knowing when to break the rules is true craftsmanship. Mark those cases as tolerated in Teamscale and document your reasoning for those you work with.
Sometimes, you hit something that’s just to big, to complete as a side job in the context of your current work. That’s fine. Simply create a respective maintenance ticket that goes into the regular work-management process.
Why Quality Gates?
Using merge requests as your quality gates is an effective means to establish high quality standards and even improve the quality as you go along.
It’s a waste of time to have a human do what a tool could’ve done before. Therefore, cleanup everything that a tool like Teamscale finds, before bringing a human reviewer.
Everything you need to know about using merge requests as your quality gates. Can’t find the answer you’re looking for? Please chat to our friendly team.
Merge requests encapsulate a coherent change. This makes quality feedback quite specific and actionable. Also, delaying a particular merge request does not block integration of other merge requests. And, finally, merge requests are an explicit part of your development process, which makes quality expectations explicit and even allows to enforce them.
By setting the quality bar high on merge requests, you effectively prevent technical debt from creeping into your main line. And at comparably low cost, because it’s still early in the process!
Teamscale integrates with GitLab, GitHub, BitBucket and Azure DevOps.
No. Sometimes there’s good reason for deviating from standards and guidelines. Which is why you tolerate findings in Teamscale and document your reasons.
Also, some things are just too big to get done as a side job. Carve them out into maintenance tickets and move on for now.
Usually, it is a good idea to do so and to document your reasoning, to avoid looking at the same finding over and over again. But this really depends on your process and how you use Teamscale. Tolerating findings is not technically required.
Would you like to exchange experiences on using merge requests?
I have dealt with establishing merge requests as quality gates for several years, working with customers who use them this way.
I’m happy to chat with you about my experience!
Companies that use Teamscale
Teamscale supports and integrates many other tools and formats.
The latest news, events and insights from our team.