Utilisation de GIT

Depuis la version 6.2.0 d'Ovidentia une nouvelle méthodologie a été mise en place pour la gestion des versions du noyau. Cette méthodologie répond à un certain nombre de besoins concernant le développement, la maintenance et le déploiement d'Ovidentia :

• Permettre de stabiliser un version d'Ovidentia sans introduire de régressions dues à l'ajout de nouvelles fonctionnalités,
• Créer rapidement des patches permettant de passer d'une version du noyau à une autre,
• Faciliter la création des Release Notes à la sortie d'une nouvelle version.

Principe des versions et des banches du noyau dans CVS

Principe des branches stables et instable du noyau ovidentia. Les ronds noirs sont les versions stables sur les branches PATCHS, les ronds blancs sont les versions bêta et les ronds gris les versions Release Candidate.

Le travail dans CVS s'éffectue sur deux types de branches : stable et instable. Les caractéristiques de ces types de branches sont les suivantes :

Les branches stables 

Elles sont nommées PATCHS-X-Y-0 dans CVS. Ces branches ne contiennent que des versions stables. Toutes les versions d'une branche stable ne contiennent que des corrections de bugs par rapport à la version initiale de la branche.

La branche instable 

Elle est nommée HEAD dans CVS. C'est la branche où ont lieu les nouveaux développements. Elle contient des versions bêta (dont le dernier chiffre est supérieur ou égal à 90) considérées comme instables et des versions release candidate (dont le dernier chiffre est supérieur ou égal à 100) considérées comme stables du point de vue des fonctionnalités mais non testées.

Les modifications peuvent avoir lieu en parallèle sur les différentes branches. En pratique elles n'auront lieu que sur la dernière branche stable et la branche instable : correction de bugs sur la dernière branche PATCHS_X_Y_0 et ajout de nouvelles fonctionnalités sur HEAD.

En effet, par principe (défini par Cantico) lorsqu'une nouvelle branche PATCHS_X_Y_0 est créée la branche PATCHS précédente est "fermée" : il n'y aura plus de nouvelle version taggée sur cette branche. Cependant des correctifs pourront être ponctuellement committés puis diffusés par la gestion des patches de cantico.fr par exemple.

Numérotation des versions

Versions bêta

Les versions bêta intègrent tout ou partie des nouvelles fonctionnalités en cours de développement dans le noyau. Elles peuvent être distribuées mais - étant notoiremment instables - elles ont essentiellement pour but d'offrir un aperçu des évolutions du noyau et de fournir une base commune pour la recherche de bugs.

Versions Release Candidate

Les versions Release Candidate (rc) succèdent aux versions bêta. A partir de la première Release Candidate (rc1), les ajouts fonctionnels sont prohibés (période dite de feature freeze) jusqu'à la création de la prochaine branche stable.

Correction de bugs

Principe

La correction d'un bug s'effectue d'abord sur la dernière branche stable (PATCHS_X_Y_0) du noyau.

Cette correction est ensuite mergée sur la branche instable.

Exemple

Si un bug est constaté sur la version 6.4.3 :

• Le développeur récupère la dernière version de la branche PATCHS-6-4-0 (checkout ou update s'il avait déjà récupéré cette branche)
• Qualifie le problème
• Corrige le bug
• Fait un commit des fichiers corrigés (toujours sur la branche PATCHS-6-4-0)
• Fait un merge des fichiers modifiés sur la branche instable (HEAD)
• Vérifie que la correction fonctionne aussi sur cette branche
• Fait un commit des fichiers corrigés (sur HEAD)
• Si nécessaire, fournit le ou les patchs au support par l'intermédiaire de l'application "Gestion des patchs" du portail extranet http://www.cantico.fr

Il appartient au développeur de s'assurer que ses corrections ont été mergées sur la branche instable de CVS.

Il appartient à la personne qui sort la version X.(Y+1).0 que les branches PATCHS ont bien été mergées.

Gestion des versions du noyau dans CVS

• Les versions stables sont celles ayant pour version X.Y.0
• Les versions X.Y.Z sont les versions patchées de la version X.Y.0
• Le nombre Y est incrémenté à chaque ajout d'une ou plusieurs petites fonctionnalités
• Le nombre X sera incrémenté quand il s'agit d'une version majeure

Pour chaque sortie de patch ou version, il faut mettre un tag sur la branche.

exemple :

• Tag version-6-2-0 sur le tronc et création de la branche PATCH-6-2-0
  • Tag version-6-2-1 sur la branche PATCHS-6-2-0
  • Tag version-6-2-2 sur la branche PATCHS-6-2-0
• Tag version-6-3-0 sur le tronc et création de la branche PATCH-6-3-0
  • Tag version-6-3-1 sur la branche PATCHS-6-3-0
  • Tag version-6-3-2 sur la branche PATCHS-6-3-0
  • Tag version-6-3-3 sur la branche PATCHS-6-3-0

Sortie d'une version majeure

Afin de facilité la sortie d'une version majeur, il est possible de créer des version intermédiaires taggées à partir du tronc avec un numéro de version mineur supérieur ou égal à 90.

Par exemple pour la version 6.3.0 :

• Tag version-6-2-90 sur le tronc
• Tag version-6-2-91 sur le tronc
• Tag version-6-3-0 sur le tronc et création de la branche PATCH-6-3-0

Programme de reprise

Lors de la mise à jour d'ovidentia, tout le programme de reprise sera exécuté, il appartient au développeur de faire les tests nécessaires afin de ne pas effectuer une action plusieurs fois. Pour chaque version, il sera possible de définir un numéro de version minimal pour l'installation d'origine d'ovidentia, dans le but de forcer des mises à jours par paliers en cas de gros écarts de version. Comme tout le programme est exécuté à chaque mise à jour cela permet de supprimer de temps en temps les parties du programme qui ne sont plus utilisées.

Par défaut, une version peut être mise à jour si le numéro de la nouvelle version est plus grand. Quand un branche de patch est prolongée au dela de la version suivante du tronc, il est possible qu'une mise à jour se fasse d'une version récente vers une version plus ancienne. par exemple de 6.2.3 vers la 6.3.0 alors que la 6.2.3 est sortie après la 6.3.0 dans ce cas il sera possible dans la dernière version d'interdire la mise à jour vers des numéros spécifiés dans la configuration.

Depuis la version 6.3.0, un log des mises à jour à été mis en place. Il peut être utilisé au moyen de 2 fonctions (bab_setUpgradeLogMsg et bab_getUpgradeLogMsg) dans le programme de reprise du noyau ou d'un module. Un identifiant unique (par module) peut être déposé avec le message de log puis la fonction bab_getUpgradeLogMsg permet de tester si le message de log existe afin de ne pas exécuter plusieurs fois une partie du programme.

Développement personnel ou expérimentation

Tout besoin de développement personnel pour des expérimentations doit se faire dans une branche à part. Le nom de la branche doit porter les initiales du développeur ayant initié la branche. Le nom de la branche commence par les initiales du développeur, un tiret, et un libellé. Par exemple : SZ-SYNCHML

Faire un update à chaque utilisation de CVS

• Avant de travailler sur n'importe quel fichier.
• Avant de faire un commit

Lire les messages de CVS à la suite d'une action

Toujours lire les messages renvoyés par CVS à la suite d'une action. ( Dans le cas de WinCVS, les messages sont affichés dans la fenêtre du bas ).

Commentaires de commit

• Lors d'un commit, donnez toujours un commentaire décrivant ce qui a été fait. Le commentaire doit être en anglais. Ne jamais laisser ce commentaire vide.

• Si la mise à jour est mineure (faute d'orthographe, correction html...), mettez Minor change afin que la personne qui lit le log comprenne que c'est bien une modification mineure.

• Si la mise à jour corrige un bug, préfixez le commentaire par BUGM #XXX :
  • BUGM : signifie que le bug est enregistré dans Mantis.
  • XXX: est le numéro du bug dans Mantis.
  • message: est un texte court décrivant le bug (Ne jamais laisser ce commentaire vide).

Le fait de donner le numéro du bug permet d'avoir plus de détails sur le bug en consultant la base de Mantis.

• Si ce n'est pas un bug, préfixez le commentaire par:
  • ENHANCEMENT : quand il s'agit d'une amélioration
  • SECURITY : quand il s'agit d'une correction relative à la sécurité
  • OPTIMIZATION : quand il s'agit d'une optimisation

Si ces commentaires doivent apparaître dans les Release Notes, il est nécessaire de créer un entrée correspondante dans Mantis (avec une sévérité correspondante) et de faire suivre le mot-clé ENHANCEMENT, SECURITY ou OPTIMIZATION du numéro du bug créé dans Mantis.

• Les messages d'un commit sur la branche PATCHS devront être recopiés lors du merge sur la branche principale en ajoutant la mention Merged from PATCHS-X-Y-0.

Exemple de commentaire d'une correction de bug sur la branche PATCH :

BUGM #124: Error SQL when you try to access calendar

Le commentaire de la même correction de bug mergée sur la branche principale :

BUGM #124: Error SQL when you try to access calendar
Merged from PATCHS-6-2-0

Client CVS

Lors de l'utilisation de wincvs par SSH, le mot de passe est enregistré en clair dans les sous-répertoires CVS de chaque répertoire du projet. Il faut faire attention de ne pas livrer un package avec les sous-répertoires de CVS.

Autre client CVS linux/windows : lincvs

Ajouter un projet dans CVS (add-on, script...)

Aucune indication sur l'environnement CVS doit être remplie car des informations doivent restées privées à Cantico.

Seule remarque : Après l'ajout d'un nouveau projet (add-on, script...) dans CVS, des droits d'accès sur la machine qui héberge CVS doivent être appliqués sur le système de fichiers. Contactez l'administrateur pour cette opération.