From b1c2179408bf123071e51f82b1412ce1b7e59f89 Mon Sep 17 00:00:00 2001 From: "G. Ann Campbell" Date: Tue, 7 Aug 2018 11:13:35 -0400 Subject: [PATCH] drop in SC where appropriate --- server/sonar-docs/src/pages/fixing-the-water-leak.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/server/sonar-docs/src/pages/fixing-the-water-leak.md b/server/sonar-docs/src/pages/fixing-the-water-leak.md index c56699733f7..95eb6e0d904 100644 --- a/server/sonar-docs/src/pages/fixing-the-water-leak.md +++ b/server/sonar-docs/src/pages/fixing-the-water-leak.md @@ -8,7 +8,7 @@ Imagine you come home one day to find a puddle of water on the kitchen floor. As Do you reach for the mop? Or do you try to find the source and fix it? The choice is obvious, right? You find the source of the leak! -So why do anything different with code quality? When you analyze an application with SonarQube and realize that it has a lot of technical debt, the knee-jerk reaction is generally to start remediating – either that or put together a remediation plan. This is like mopping the floor once a day while ignoring the source of the water. +So why do anything different with code quality? When you analyze an application with SonarQubeSonarCloud and realize that it has a lot of technical debt, the knee-jerk reaction is generally to start remediating – either that or put together a remediation plan. This is like mopping the floor once a day while ignoring the source of the water. Typically in this traditional approach, just before release a periodic code quality audit result in findings the developers should act on before releasing. This approach might work in the short term, especially with strong management backing, but it consistently fails in the mid to long run, because: @@ -29,7 +29,7 @@ As a bonus, the code that gets changed the most has the highest maintainability, ## How to do it -SonarQube offers two main tools to help you find your leaks: +SonarQubeSonarCloud offers two main tools to help you find your leaks: * Leak Period metrics show the variance in your measures between the current code and a specific point you choose in its history, typically the `previous_version` * New Code is primarily detected based on SCM "blame" data (starting from the first analysis within your Leak Period), with fallback mechanisms when needed. See SCM integration for more details. -- 2.39.5