Klarity

Appearance

:back_arrow: General Concept Elements - Concept & Definitions

👁 "This page must still be reviewed and validated by Safenai when evolution for V1.0 will be performed"
👁 " but it's content is consistent what have been implemented so far (26/05/2024)

Project Configuration Item Version Management in Klarity dashboard ​

In klarity dashboard, we manage the lifecycle of Project Configuration Item.

Most of the version management will be handle by gitlab, and we will not describe them here. Here we discuss of version what will be manage in Klarity Dashboard (KD), there will be more detailed versioning in gitlab for the artefacts.

Some generalities : ​

  • We will have several version of project we handle simulteaneously.

  • most data associated to a project from klarity dashboard point of view are immutable.

  • A same version can not be pushed several time

  • We can have multiple version at the same time but only one active per stage, exemple

    • We have already validate the scoping of V0 and V1, the current version to validate is V2
    • We have already push in production V0.2 and we are currently working on V1.1
    • V0.2.z is in production since z-1 “epochs”

  • As only validated dev version only are put in production, and as version are immutable, not all digit will be put in production when some request of evolution are performed.

Project Configuration Item lifeclycle ​

  • PCIV Vx.0.0 is created in gitlab and pushed into usign Klarity Craft and triger creation of a PCI.
  • Klarity Dashboard handle Validation status of version content in scoping stage for this version.
  • On user validation action this version is switch to develpment stage by KD User.
  • From Klarity Craft development Artefacts will be filed, and a new version Vx.y.0 is pushed to klarity Dashboard for development decision
  • Klarity handle Validation status of version content in development stage for this version.
  • On user validation this version is switch to operation stage by user.
  • On user validation this PCI is rejected.

Project Configuration Item Version Structure ​

PCIV Each version has 3 digit Vx.y.z :

  • X scoping version

  • Y development version

  • Z operation epochs

    Epochs granularity might be different between projets (second / hours / days / batch / ….), this granularity will be used to version operation data

Active version management in klarity ​

When a version is push for a specific stage in Klarity :

  • If no other version are active in this stage, it become the active version.
  • If user switch active version to an other stage, next available version become active.
  • User can select an available version to become active. (not yet implemented)

NOTE : We will recommand to limit the number of the available versions. (if well utilize there in no need in decision dashboard to have a lot of version) NOTE_2 : We might want to compaire different version present in a dedicated stage.

Nominal interaction between KM and KD ​

Operation for version in operation ​

An other sequence diagriam to describe alternative action for a version in opération

Details on interaction describe in Diagram ​

Need validation of Vx.0.0 in "Scoping" ​

With this opération :

  • A PCIV is pushed from KM to KD Scoping Stage.
  • All the content of the PCIV is immutable.
  • Vx.0.0 is visible
  • Vx.0.0 has the project status "NEED_VALIDATION"

Validate and comment Vx.y.0 content ​

Behind this action, we have several user action that will validate and comments metrics of the PCIV. The accountability of these comment are managed by Klarity Dashboard (KD), and shall rely on multiple users.

Validate Vx.0.0 as ready to Dev ​

When the Validation button is activate on the PCIV, this action triger the internal operation of Create Vx.1.0 in "Dev"

Create Vx.1.0 in "Dev" ​

A new PCIV Vx.1.0 is created by Klarity Dashboard (KD).

This new version content :

  • a reference to the Vx.0.0
  • All the messages, validation and associated accountability informations.
  • Vx.0.0 became inactive
  • Vx.1.0 has the project status "ALREADY_VALIDATED"
  • Vx.1.0 is visible in Scoping and Dev Stage

Need development of Vx.y.0 ​

Once PCIV Vx.y.0 created, a gitlab issue is create in KM with a json containing validation information and accountability associated.

Need validation of Vx.y.0 in "Dev" ​

After develpment of content associated to PCIV Vx.y-1.0 :

  • a Vx.y.0 is pushed from KM to KD Development Stage.
  • All the content of the PCIV is immutable.
  • Vx.y.0 is visible in devlopment scope
  • Vx.y.0 has the project status "NEED_VALIDATION"

Validate Vx.y.0 as ready to Operation ​

When the Validation button is activate on the PCIV, this action triger the internal operation of Create Vx.y.1 in "Operation"

Create Vx.y.1 in "Operation" ​

A new PCIV Vx.y.1 is created by Klarity Dashboard (KD).

This new version content :

  • a reference to the Vx.y.0
  • All the messages, validation and associated accountability informations.
  • Vx.y.0 became inactive
  • Vx.y.1 has the project status "ALREADY_VALIDATED" // TODO adjuct status
  • Vx.y.1 is visible in Scoping, Dev and Operation Stage

Need deployment of Vx.y.1 ​

Once PCIV Vx.y.1 created, a gitlab issue is create in KM with a json containing validation information and accountability associated.

Operation feedback from Vx.y.z in "Operation" ​

After deployment of content associated to PCIV Vx.y.1 :

  • a Vx.y.z (z > 1) is pushed from KM to KD Operation Stage.
  • All the content of the PCIV is immutable.
  • Vx.y.z is visible in operation scope
  • V0.2.0 has the project status "TBD" TODO

State management for PCIV ​

The management of the PCIV by Klarity Dashboard (KD) rely on the following state :

  • validation status
  • active state
  • active stage

Bellow the state machine, and activity diagram for complexe transitions

TODO : make activity diagram for Activation / desactivation.