Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-938

Governance should support the concepts of "Application" and "Portfolio"



    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:


      The Problem

      For the time being the governance product only targets Managers/Executives by providing a way to get a high level perspective on an aggregation of projects. You can easily aggregate from few projects to thousands with any level of tree depth.

      But from time to time, development teams would also like to use the governance product to fulfill their day to day needs, and especially to group a few highly-coupled projects into one application so it can be dealt with as if it were a project.

      Let's imagine for instance a team A in charge of several projects and two of them (P1 and P2) share the same development lifecycle because they are part of the same functional application. In such case, team A would like to group P1 and P2 into one A1 application and to retrieve on A1 the standard SQ project homepage and a Quality Gate status in place of the current Releasability rating.

      Actually, that's pretty usual when creating an aggregation tree to have the first level of the tree representing an application and then the other upper levels being more organizational (team, department, business unit, ...).


      • The Projects in an Application really do have the same lifecycle, and so are released within minutes or hours of each other
      • The Projects in an Application have the same leak period setting, whether that's previous_version, a date, or a number of days.

      The Solution

      The idea is to provide the ability when creating a new portfolio to choose its nature: either this is an "Application" or a "Portfolio" .

      Names that were Considered and Rejected for "Portfolio"
      "Organizational" - too close to "Organization"
      "Management" - somewhat pejorative
      "Overview" - too... abstract?


      • An application is composed only of projects.
      • A portfolio may be composted of projects, applications, and other portfolios.

      As is currently enforced for portfolios, you should not be able to add a project to the same application twice.


      No major changes are anticipated in the Application/Portfolio creation and management interface except

      • the addition of type selection at creation
      • the use of the Application icon (see below) as appropriate
      • the restriction to only adding Projects to an Application


      Application measures are calculated at the same time and in the same manner as portfolio measures

      Metrics & Leak Period

      The Reliability, Security and Maintainability ratings must be computed for applications the same way they are computed at project level (the algorithm described in MMF-469 must be used only for portfolios)

      No Releasability Rating should be computed. Instead, a Quality Gate Status should should be computed, based on the worst quality gate status for all component projects.

      Leak period

      Applications do not have leak periods as such; their leak period measures are all based on aggregate values from their component projects' leak measures. Leak metrics will be calculated without regard to any date differences between the projects and the application. Instead, these calculations will be based on the projects' leak metrics.


      The homepage of an application must be similar to the Project homepage with Bugs, Vulnerabilities, Code Smells, Code Coverage, Duplications, and a leak period

      Leak Period

      This portion of the page should simply say: "Leak Period", with a mouseover that lists all component projects and their leak starts. The point of this is to give a quick overview of leak starts so that it is easy to spot when one or more project leak periods is out of alignment.

      Quality Gate

      When the application fails its quality gate, displaying each individual failing quality gate metric could overwhelm the page very quickly for large applications. Instead, there should be only a single Failure/Warning block per project. That block should list the project name, and each failure/warning condition and value. Each condition/value pair should click through to the same place it does from the project's homepage.


      2 New Bugs > 0 (link to project issues page)

      1 New Issues > 0 (link to project issues page)
      1 Skipped Test > 0 (link to project metrics page)

      Quantitative values

      The right column of the homepage should follow the project pattern, but omit a few things:

      • Quality Gate (could vary by project)
      • Quality Profiles (could vary by project)
      • Links (not settable at portfolio level and will vary by project)
      • Executive Report (PDF) section from the Portfolio homepage

      Code Projects (Project-level)

      The project Code page must be relabeled Projects. Its top level should list component projects or applications. The renaming is desired to make it clear where to find the list of component projects and how to drill to their values.

      The contents of this page should be a hybrid of the Portfolio Projects page and the Project Code page. Specifically, the values listed for each component should be

      • Quality Gate Status - as for a Portfolio
      • Lines of Code
      • Bugs
      • Vulnerabilities
      • Code Smells
      • Coverage
      • Duplications

      Clickthroughs should work as they do on the Portfolios "Projects" page.


      The activity page should treat each portfolio calculation as a "snapshot" and work just the same as for projects.

      The Create (event) and Delete functions should remain available on this page for users with the required perms. While the ability to create custom events should be retained, the ability to add a version event should not since "versions" as such in an application have no relevance; the leak period cannot be set from them and without that they are simply labels.


      The settings section should echo the settings for Portfolios, so the following sections should be available and work as they do for portfolios:

      • Custom Measures
      • Permissions
      • Background Tasks
      • Edit Application
      • Deletion - as with Portfolios, deleting an Application should not delete the aggregated projects.

      The following sections should be omitted:

      • General Settings - leak period is the only setting in this section for portfolios, and it will be removed. There is no need for a General Settings section for Applications
      • Executive report - no executive report will be available for Applications, at least in a first version.

      To be explicit, the following settings that are available for projects are not needed for Applications:

      • Quality Profiles - this should be set at the global or project level
      • Quality Gate - this should be set at the global or project level
      • Links - this may be added in a future version but is not required now
      • Import / Export - this should be done at the global level

      Measures page

      The Measures page should work just the same as for portfolios.

      Portfolios (global)

      Applications will appear in the portfolios page. The card for an application should show the quality gate status and the 5 principal measures that appear on ProjectS cards. The total LoC should be shown, as with Portfolios, but there is no need to show the contributing languages. Nor is there a need to show (from the Projects card) the date of the application's last calculation; this is presumably scheduled to run on a regular basis.


      A separate icon must be crafted for this portfolio type and used in all places icons appear.



      All existing portfolios must remain portfolios. Specifically, there is no migration.


      Because of the impossibility of correctly filling in the history, no option to manually migrate an portfolio to an application, or vice versa, will be offered. This means that users desiring such migration must manually recreate the existing portfolio as an application and (presumably) delete the portfolio.

      Potential features for future versions

      • Moving Applications from Portfolios page to ProjectS page
      • Warning (UI? Logs?) when max(project leak) - min(project leak) > 1week
      • Ability to tag applications
      • An option to automate the manual migration steps, E.G. "Migrate Without History"
      • Projects Search facet to search for projects by encompassing application
      • Handling the fact that creating links to "new" issues by concatenating all relevant project ids into the URL could lead to hitting URL-length limits for large applications.
      • Dealing with any new/old issue inconsistencies caused by the use of a date parameter versus time zone differences.
      • Addressing organizations in any way

      Current Design proposition

      Configuration of Applications

      In the Administration top-level entry > Configuration > Portfolios, when the user clicks on the "Create" button, two options will be available on the form of radio buttons: "Application" or "Portfolio". Each one should display a short description so the user gets the difference between the two:
      Application: Single-level aggregation with a technical focus and a project-like homepage
      Portfolio: Potentially multi-level, management-oriented overview aggregation

      After an Application is created, it will appear in the list of Portfolios in the left column. When clicking on an Application in that list to add some projects to it, the middle column will disappear. The right column will not display the button "Add Portfolio" anymore, nor the possibility to change selection mode (always manual).

      Displaying Applications in the Portfolios page

      Applications display project-like informations, with bigger size to better match the Portfolios page layout.

      Short description is displayed on hover on the icon. It will also be the case for the Portfolio icon.

      Application's Homepage

      Homepage overview is very similar to a Project's homepage. Differences are:

      • "Code" tab is renamed "Projects tab"
      • There can be only one failed quality gate condition box by project. Its border color depends on the worst failed condition.
      • Leak period is renamed "Max Leak Period", and inherits from the project having the oldest leak period start date.
      • We still display last analysis date in the top right corner but not the version
      • In the aside column, we do not display tags, languages, quality gate, quality profiles and links. However we display the number of projects.

      The "Projects" tab will display the list of projects and main metrics in the same fashion than a portfolio's "Projects" tab.


          Issue Links



              ann.campbell.2 Ann Campbell
              freddy.mallet Freddy Mallet (Inactive)
              1 Vote for this issue
              5 Start watching this issue