Objectives

Ensure:

• Code reliability: Sufficient testing, good and perennial architecture.
• Good semantic: Code understanding over non updated comments.
• Industry standard adoption: Share knowledge of best practices.

Code lifecycle

graph TD;
    A[Ready] -->|Discussion & Refinement| B(Ongoing)
    B -->|Développement & Tests| C[Code Review]
    C -->|Validation par les pairs| D[PO Review]
    D -->|Validation fonctionnelle| E[QA Review]
    E -->|Tests de régression| F[Ready-to-MEP]
    F -->|Déploiement & Documentation| G[Closed]

    G -->|Préparation de Release| H[Releases]
    H -->|Vérifications finales| G

    G -->|Détection de bug critique| I[Hotfixes]
    I -->|Correction rapide| G

Each issue in our git repository adopt the following statuses:

ready

• Issue has been written by the product owner with the assistance of the UX designer if required.
• Issue has been discussed in pre-refinement with the product owner, the principal engineer, the VP of engineering, a lead developper, and the CTO.
• Issue has been discussed in refinement with all the developers of the squad. In this phase, all impacts on our architecture have been defined.
• All impacts have been weighed during a poker planning by the developer's squad.
• During the sprint planning, the Issue has been accepted in the current sprint depending on the squad velocity.

ongoing

• The developer assigns themselves on the issue.

• They create a feature branch, following the git flow branch model.

• The name of the branch uses this naming convention:

  features/issueNumber-kebab-cased-title-of-the-issue.

• The developer resolves the issue.

• Their code editor performs linting in real time and on each file save, a prettifying of the file is performed.