General release cycle

Cycle de développement

Itération

Le cycle de développement est formé de multiples itérations. Une itération se compose elle-même de 3 processus communicants et autonomes:

• Demande de fonctionnalités (feature request)
• Développement des fonctionnalités (feature development)
• Mise en production (migration)

Les processus techniques sont décrits en détail dans la recette relative.

Demande de fonctionnalités

Phase administrative composée des étapes

• L'utilisateur écrit une demande en forme de commentaire sur la page wiki (fixme: wiki page link)
• La demande est validée lors de la prochaine séance
• Une demande wiki est créée (example, création d'une nouvelle demande) (fixme: example wiki page link)

Développement des fonctionnalités

Phase technique composée des étapes

• La demande wiki passe en état "A implémenter"
• Un ou plusieurs ticket(s) github sont créé, avec réf. vers la demande wiki
• La fonctionnalité est développée et testée par le développeur

Mise en production

• La migration est effectuée sur l'instance de release -
  la migration des données est également testée par le développeur avec une copie des données de production
• La fonctionnalité est testée et validée par les utilisateurs -
  en cas d'anomalie (bug), la fonctionnalité est corrigée et le processus de mise en production est recommencé -
  après validation, aucune modification ne peut plus être apportée à la fonctionnalité
• La migration est effectuée sur l'instance de production -
  les données de production ont été préalablement sauvegardées
• La demande wiki est archivée et les tickets github fermés -
  en cas d'une détection d'anomalie (bug) à posteriori, une nouvelle itération est mise en place.

Versioning

Structure du système de version: x.y.z (eg. 1.0.0)

• x: Major version: Updated on: Major architecture/conceptual change leading to incompatibilities
• y: Minor version: Updated on: Feature addition, modification, removal
• z: Subminor version: Updated on: Hotfixes

Migrations

Une migration est effectuée lorsqu'il faut modifier une partie de la base de données (structure ou données) et s'effectue généralement lors de l'implémentation de fonctionnalités.

Par exemple, une fonctionnalité demandant d'ajouter un champs de type liste déroulante nécessite de modifier la base de données en créant un catalogue contenant les options de la liste.

Création d'une migration

Une partie de ces étapes est commune avec le déroulement d'une mise en production.

Création de la migration

1. Créer le ticket sur github pour la fonctionnalité ou la migration
2. Créer la branche git et développer
3. Lancer les tests unitaires
4. Créer le script de migration nommé issue#{numero}-nom-de-la-branche-git dans scripts/migrations/.
   La migration doit se faire à partir du tag git correspondant à la version de production.

Test de la migration

1. Se positionner sur le tag git correspondant à la version de production actuelle
2. (Re)déployer la base de données de l'application from scratch et tester le bon fonctionnement de l'application
3. Exécuter le script de migration et tester le bon fonctionnement de l'application
4. Lancer les tests unitaires

Git branching model

Lors du développement de fonctionnalités, nous utilisons le modèle de branchage git suivant.

Principes

• Master branch is never use to commit directly.
  Any development (new feature, modification or bugfix) has to be made in a dedicated branch.
• Releases are made by tagging the master branch with a release tag.

Schéma

Source: http://nvie.com/posts/a-successful-git-branching-model/