Stop planning; fix the leak!
So there you are: you've finally decided to install the SonarQube platform and run a couple of analyses on your projects, but it unveiled so many issues that your team doesn't know where to start. Don't be tempted to start fixing issues here and there! It could be an endless effort, and you would quickly be depressed by the amount of work that remains. Instead, the first thing you should do is make sure your development team fixes the leak. Apply this principle from the very beginning, and it will ensure that your code is progressively cleaned up as you update and refactor over time. This new paradigm is so efficient at managing code quality that it just makes the traditional "remediation plan" approach obsolete. Actually, so obsolete that related features will disappear in SonarQube 5.5: action plans and the ability to link an issue to a third party task management system.
"Why the heck are you dropping useful features? Again!?..."
Well, we've tried to dogfood and really use those features at SonarSource ever since we introduced them - but never managed to. Maybe the most obvious reason we never used them is that far before conceptualizing the "Leak" paradigm, we were already fixing the leak thanks to appropriate Quality Gates set on every one of our projects. And while doing so, nobody was feeling the need to rely on action plans or JIRA to manage his/her issues.
There are actually other reasons why those features never got used. First, action plans live only in the SonarQube server, so they don't appear in your favorite task management system. Because of that, chances are that you will eventually miss the related dead-lines. This is why you might be tempted to "link issues" to your task management system. But this "Link to" feature isn't any better. Let's say you're using JIRA in your company. When you link an issue to JIRA, the SonarQube integration automatically creates a ticket for that issue. So if you want to keep track of 100 issues, you'll end up with 100 JIRA tickets that aren't really actionable (you just have a link back to SonarQube to identify every single issue) polluting your backlog. What's even worse is that when an issue gets fixed in the code, it will be closed during the next SonarQube analysis, but the corresponding ticket in JIRA will remain open! Anyway, issues in the SonarQube server and tickets in JIRA just don't have the same granularity.
"Still, there are cases when I really want to create a remediation plan. How can I do that?"
As discussed previously, you should really avoid defining a remediation plan, and take the opportunity instead to spend the energy on "fixing the leak" instead. Still, occasionally, you might be forced to do so. The main case we can think of is when you absolutely want to fix critical bugs or vulnerabilities found on legacy code that might really affect your business if they pop up in production. In that scenario, indeed you might want to create a dedicated remediation plan so that your development team gets rid of this operational risk.
The good thing is that SonarQube already has everything you need to clearly identify all those issues and plan a task to make sure they got fixed - whatever task management system you're using:
1. In the SonarQube UI:
- Start tagging issues you want to fix with a dedicated and specific tag, like "must-fix-for-v5.2"
- Create a public "issue filter" that displays only issues tagged with "must-fix-for-v5.2"
2. In your task management system:
- Create a ticket in which you reference the URL of the issue filter
- Set a due date or a version
3. You're done! You have a remediation plan that you can manage like any other task and your team won't forget to address those issues.
"I don't need anything more then?"
Well, no. Defining remediation plans this way gives the best of both worlds: identifying issues to fix in the SonarQube UI, and planning the correspond effort in your own beloved task management system.
And once again, remember that if your team fixes the leak, chances are you will not need to create a remediation plan any longer. So yes, even if I'm the one who initially developed Action Plans and the "Link to" features a long time ago, I think it's really time to say bye bye...