As soon as you start dealing with hundreds or thousands of SQ projects and want to create several aggregation trees to manage your assets, creating and maintaining those trees can be quickly become painful and error prone. Indeed, the structure of those trees is currently highly static in SQ and the management is centralized. So if you have a tree with thousands of leaves, the likelihood to have this tree never really up-to-date is really high:
- When a project P1 is removed, this project P1 must also be manually removed from the aggregation tree
- When a project P2 is created, someone should not forget to manually update the aggregation tree
- When a project P3 is moved from one team to another, someone should not forget to manually update the aggregation tree
Whereas in all those cases, no one should have to update the aggregation tree because fundamentally its structure is the same.
By using project tags it should be possible to perfectly define the structure of an aggregation tree (Portfolio) without hard coding each SQ project in the portfolio. By doing that the definition of the structure remains highly centralized and controlled by only a few people while the way each project should be attached to an aggregation tree becomes more dynamic and decentralized. Specifically, since the ability to edit tags on a project rests with a Project Administrator, she then gains the ability to add or remove her project from any particular portfolio
When creating a portfolio, there are currently four ways to attach a project to it:
- By Custom Measure
- By Regular Expression
- All Remaining Projects
We should deprecate:
- By Custom Measure
- By Project Tag
- It should not be possible to reuse the same project tag several times in the same aggregation tree.
- It should be possible to define multiple inclusion tags for a portfolio. These will be OR-ed together, such that if the portfolio includes 'foo' and 'bar', all of the following will be included: Project A with only the 'foo' tag, Project B with only 'bar', Project C with both 'foo' and 'bar'
UX Workflow in the Administration console:
Please note that the multiselect component is already in use in SonarQube (Issues page, hit "Bulk Change", then "Add tags")
- Using "Manual Measure" was just a workaround while waiting for project tags, so eventually we should drop the 'By manual Measure' option. However, that must be done in a later stage so users have the chance to transition portfolios currently defined by measures.
- Adding a tag to an Application so that they can be included in Portfolios created via tags (see
- Add deprecation notice to Manual Metric / Measure UI
- Add deprecation notice on 'By Manual Measure' in Portfolio Selection Mode dialog's dropdown
- Update api/views/mode in order to make parameter selectionMode accept the new value TAGS
- Create api/views/set_tags_mode with the following parameters :
- portfolio : portofolio or sub portfolio
- tags : list of tags to be used to know which project should be included
- Update api/views/define to accept projects selection by tags
- Create api/views/set_manual_mode
- Create api/views/set_remaining_projects_mode
- Create api/views/set_regexp_mode and deprecate api/views/regexp
- Deprecate api/views/manual_measure
- Deprecate api/views/mode
- Computation of portfolio/sub-portfolio must take into account projects selection by tags
- Fail when same tag is used in Portfolio and in a sub-portfolio
- Fail when same project is added by different tag
- For instance, it should fail when project is added to portfolio via tag 'foo' and to its subportfolio via tag 'bar'