Merge Request Integration: Your quality gate

Merge Request
Integration

Teamscale turns your merge request (or pull request) into your quality gate. Set the quality bar high for every change that’s going to be integrated into your main line, and steer towards acceptance sure-handed, with continuous feedback.

Request a demo

Your merge request

Your quality gate

Quality issues

Test Gaps

∞

Feedback

Don’t Merge Until it’s Clean

Establish »quality doors«

Traditional quality gates typically permit changes with low quality, because their feedback comes so very late in the process that it is difficult and costly to act on. Therefore, Teamscale establishes smaller »quality doors« at each merge request, where feedback is personal and actionable and you still have time to process it.

Learn more

Set clear expectations

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.

Integrate It

Into your code collaboration platform

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.

Learn more

Badge, vote or comment

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.

Learn more

Put it to Use

Fix things

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!

Document deviations

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.

Learn more

Carve out the big fish

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?

Deliver high quality

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.

Save the reviewer’s time

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.

Support

FAQs

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.

Why do traditional quality gates fail?

Quality gates, when established towards a release, typically permit low-quality changes into our systems, because turning them away would mean to exclude them – and possible even other, related changes – from the release, which is usually costly. Moreover, it is often difficult to act on the feedback from such a quality gate, because you need to pick up context again, before you can address them.

Why are merge requests effective quality gates?

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.

What are the benefits of using merge requests as quality gates?

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!

What platforms does Teamscale integrate with?

Teamscale integrates with GitLab, GitHub, BitBucket and Azure DevOps.

Do I need to fix all findings?

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.

Should I tolerate all findings that I don’t resolve?

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.