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

Choose New Code baseline analysis from UI





      In MMF-1524 we added the ability to manually choose a specific snapshot as the New Code Period baseline. The primary target for manual baselines in that sprint was providing web services so that automation systems such as Burgr (our internal system) can mark the relevant analysis as the new New Code Period baseline when a release is performed. With that done, we'd also like to provide the ability to invoke those web services from the UI. Not everyone has a Burgr, and we should make it easy for people who haven't automated the setting of a manual baseline to use the functionality.

      Additionally, once the concept of manual baseline is introduced, it becomes obvious that it would be beneficial to indicate in the UI which is the baseline analysis, whether that baseline is automatically chosen or manually set. For instance, if I set the New Code Period to 1/1/2019, and there are 3 analyses on record for that date, which of them is the baseline, and which if any are in the New Code period? Currently, this is very difficult to know and entirely opaque to the average user.


      We must also expose the ability through the UI to manually set the baseline analysis. This option should be given at branch level, where it makes sense to select a specific analysis.
      And, with the addition of this possibility, setting a specific date as the New Code Period value of a branch becomes less useful. It will be removed and replaced by the "specific analysis" setting.

      Additionally, since the use of the word "since" has proven confusing in the project homepage New Code period label, we'll swap in "after" when a date is used.

      Also, in the Activity page,

      • the page should show the baseline marker of the current branch
      • when a specific analysis is set as a baseline, the analysis should not be deletable.

      Make new code period setting more visible:

      • At global level: the setting will move under a new sub-menu: Administration>Configuration>General Settings>New Code Period
      • At project level: the setting will move under a new entry: Administration>New Code Period (currently under Administration>General Settings).

      Avoid irrelevant new code values

      Some existing values are not relevant anymore and should disappear from the interface: custom date or a specific version 

      • At global level: specifying a same starting version or date for all the projects doesn't really make sense.
      • At project level: setting date or a version would be something specific to projects branches since those settings have different meaning for each branches: The first analysis that exists in the branch after the corresponding date is the start of the new code period. These values are now replaced by selecting a specific analysis.

      Global settings vs project settings

      The current pattern is that global is a default, overridden by project settings. We are keeping this pattern. E.G. If an administrator changes global settings at some point it won’t override personalized project settings.

      The project-level setting UI will include an explicit way to remove the project-specific setting so that the project follows the global setting.

      Migration from past SQ versions

In case a specific date or version was set globally, the global setting should come back to the default value (previous version) and all the projects which don't override the global value should be migrated.

      In case a specific version applies at project level (inherited from the global value or specially set on the project), the version was set to correspond to a version which exists only in the main branch.
      Whether a version of a date was specified, the new code for all the other branches was thus starting with the first known analysis of the branch and, considering that there's a purge mechanism for old analyses, the behavior of the leak period was not deterministic for the end-user.

      • The project setting should come back to the default value.
      • For the main branch, the first snapshot available with this version/date in the main branch should be set as the baseline for the new code period. In case, no analysis is not found, project setting should return to default.
      • For the branches which don't yet override this value, the first snapshot available for this same date should be set as the baseline for the new code period.

      Migration from CE to DE

      If the new code period is set to a "specific analysis" of the main branch in CE, once SQ upgraded to a DE, the default value (i.e. the global value) should  apply at project level.


      To view micro interaction descriptions and additional information make sure to activate comment mode (bottom right corner)


      Note that the wireframe doesn't exactly correspond to the implementation that will be done.

      Corner cases

      Because this old way to configure New Code Period was permissive, we must consider corner cases:

      • The user has set a specific version as baseline and then rendered the selection invalid by E.G. deleting the relevant snapshot.
      • The user has set a specific analysis date as baseline but no analysis can be found

      In both cases, the answer is the same: The configuration was incorrect and would have fail the next analysis,. We'll fall back to the default mode.


          Issue Links



              christophe.levis Christophe Levis
              ann.campbell.2 Ann Campbell
              0 Vote for this issue
              5 Start watching this issue