Est-il nécessaire de présenter la notion d'intégration continue (Continuous Integration) ?

Le principe (en résumé) est le suivant : chaque fois que le développeur contribue au projet en ajoutant une mise à jour ou un fichier au dépôt central (on parle de commits), le projet est automatiquement recompilé, testé, et éventuellement délivré à nouveau.

C'est le travail du serveur d’intégration que d’automatiser ces tâches. En l'occurence, nous utilisons Cruise Control.Net que nous avons configuré pour supporter le principe d'organisation des codes sources mis en place dans le projet CiviKey et présenté précédemment.

Les quatres actions de base sont :

1. Compilation en mode Debug
2. Tests unitaires
3. Compilation en mode Release
4. Tests FxCop

Ces actions sont lancées après un commit (toute modification) dans :

• /trunk
• /releases/{VERSION}/trunk
• /releases/{VERSION}/tags/{TAG}

Lors d’un commit dans /trunk il y a en plus une vérification du contenu du commentaire. S’il contient [DoRelease] ET que le fichier release.txt a été modifié (ie. il fait partie du commit - ceci est une sécurité) alors une nouvelle version sera créée automatiquement lors du commit (et donc une compilation du trunk de la version sera effectuée).

Le fichier release.txt se présente de la façon suivante :

# This file is used to generate a new Release branch.
# It contains:
#   - ReleaseNumber: RELEASE-NUMBER (format X.X.X like 2.4.12 - major.minor.revision expected)
#   - RevNumber: OPTIONAL-REVNUMBER-TO-RELEASE
#       This is optional: it enables a "release from the past" if needed.
#       By default, we take the SVN « RevNumber » of this file: 
#       since this file necessarily belongs to the commit, it is the current (the 'head' revision) /trunk version.

ReleaseNumber: 2.4.7

# RevNumber: 10 (Optional: to be used only if one want a Release based on a /trunk past version.)

Lors d’un commit dans /releases/{VERSIONS}/trunk il y a en plus une vérification du contenu du commentaire. Si il contient [Tag] ET que le fichier tags.txt a été modifié alors un tag sera créé dans cette version automatiquement lors du commit (et donc une autre compilation, mais de la version taguée sera effectuée).

Le fichier tags.txt se présente de la façon suivante :

# This file is used to generate a new Tag.
# It contains:
#   - TagName: OPTIONAL-TAG-SUFFIX
#   - RevNumber: OPTIONAL-REVNUMBER-TO-TAG
#       This is optional: it enables a "Tag from the past" if needed.
#       By default, we take the SVN « RevNumber » of this file: 
#       since this file necessarily belongs to the commit, it is the current (the 'head' revision) /releases/{VERSIONS}/trunk version.

TagName: Final

#RevNumber: 10

Lors de la création d’un tag /releases/{VERSION}/tags/{TAG} il y a la génération de l’aide correspondant à cette version (CHM + site web) ainsi que la génération du package pour cette version.

Grâce à tout cela, CiviKey est définitivement sous contrôle !

Nous avons vu dans un post précédant que le serveur SVN pour CiviKey était accessible via l’url http://svn.invenietis.com/svn/CK et que le serveur d’intégration continue était accessible à l’URL http://ci.civikey.invenietis.com/.

Dans ce post nous allons voir la gestion du repository SVN ainsi que de Cruise Control .NET pour le projet CiviKey. Ce qui est présenté ici n'est mis en place que pour la version 2.5 de CiviKey (celle sur laquelle nous concentrons actuellement nos efforts).

Le repository SVN

Le noyau de CiviKey est divisé en deux: le Core, qui contient le noyau proprement dit et Certified qui contient les plugins certifiés. L’architecture globale est la suivante :

Organisation des Versions

Les "releases" sont gérées à de la façon suivante. Le projet DEMO (qui est un projet similaire à Core) détaille l'organisation de l'arborescence des releases :

Ce système nous permet de gérer au mieux la montée en version du projet tout en préservant la liberté du développeur. Et il y tient le développeur à sa liberté.

Une petite histoire

Les développeurs travaillent dans /trunk qui est l’espace de développement principal.
Ils font des évolutions, des changements dans l’API pour mettre en place les nouveautés, et, un jour une version est prête à voir le jour, les développeurs décident donc de créer une Version, disons la 2.5.0.

Un nouveau dossier est créé dans /releases : /releases/2.5.0/trunk. Une Version est née, elle n'est pas parfaite (elle va avoir besoin de quelques retouches pour être finalisée) et va donc évoluer et donner naissance à des Tags.

Le premier de ces tags s'appelle CTP (pour Community Technology Preview, il aurait pu s'appeler Alpha ou PreAlpha ou autre nom qui indique que ce n'est pas vraiment sec) : /releases/2.5.0/tags/CTP apparait dans l'arborescence. Noter que les codes sources dans /tags n'évoluent pas: ils représentent des clichés, des instantannés, du /releases/2.5.0/trunk qui leur a donné naissance. Le trunk bouge, les tags figent.

Cet espace permet aux développeurs de continuer à travailler dans /trunk et donc de continuer à faire évoluer le noyau, pendant que d’autres travaillent pour la Version /releases/2.5.0/trunk afin de régler les derniers bugs qui pourraient exister. Une fois les derniers bugs corrigés dans le /trunk les développeurs créent le tag /releases/2.5.0/tags/Final (et espèrent très fort éviter le petit frère /releases/2.5.0/tags/SP1).(Voir http://en.wikipedia.org/wiki/Software_release_life_cycle pour des exemples de noms de révision.)

Pendant ce temps les développeurs du /trunk se sont lancés dans la future version 2.5.1 et ont d'ores et déjà produit une release en Alpha ce qui signifie qu’un dossier /releases/2.5.1/trunk a été créé ainsi qu’un tag /releases/2.5.1/tags/Alpha.

Cette petite histoire nous amène au dépôt suivant :

Avec ce système la version d’un projet à une vraie existence : les corrections sont possibles sans (trop) d'interférences ce qui libère le développeur, qui sait clairement s’il peut imaginer de nouveaux bugs (/trunk) ou s’il doit réfréner sa créativité (/releases).

Invenietis a mis en place, pour le projet open source CiviKey, une infrastructure complète de gestion de projet technique. Cette infrastructure va continuer d’évoluer dans le temps, mais la base décrite dans ce poste est en place. Un autre post sera dédié à la gestion du repository SVN (dépôt SVN en français) et du serveur d’intégration. Nous avons choisi de mettre en place un certain nombre de services que l’on retrouve dans un grand nombre de projets. Ces services ont été mis en place à l’aide d’autre projet Open Source et à des modules spécifiquement développés pour la problématique de CiviKey.

Gestion du projet

La gestion projet a été déléguée à un outil fonctionnant en Ruby, Redmine (http://www.redmine.org). Il est utilisé par Invenietis en interne pour la gestion de projet ainsi que pour le dialogue avec nos clients. Cet outil permet de gérer l’ensemble des tâches lié à un ou plusieurs projets en proposant une interface web simple et un environnement unique. (Pour ceux qui connaissent, c'est un Track simple, fonctionnel, et multi projet.)

Ce service est accessible via l’URL : http://civikey.invenietis.com/

Repository SVN

La gestion des sources a été déléguée à un serveur SVN sous Windows à l’aide de VisualSvn Server (http://www.visualsvn.com/server/). Ce serveur donne accès à l’ensemble des sources du projet CiviKey.

Compte tenu du refactoring (assez violent) en cours, les dépôts de la version 2.0 et 2.5 n’ont pas la même structure.

Version CiviKey 2.0 :

         Core : https://svn.invenietis.com/svn/CK/branches/Core-Summer09

         Contrib : https://svn.invenietis.com/svn/CK/trunk/Contrib

Version CiviKey 2.5 :

         CK.Core : https://svn.invenietis.com/svn/CK/Core/trunk

         CK.Certified : https://svn.invenietis.com/svn/CK/Certified/trunk

Un premier autre post sera dédié a la gestion du repository par rapport à la gestion des releases et des tags de version.

Service d’intégration continue

Pour garantir la qualité des éléments développée dans ce projet, nous avons mis en place un service d’intégration continue qui permet de faire un ensemble d’opérations à chaque commit de développeur. Ce service a été mis en place grâce à Cruise Control .NET (http://ccnet.thoughtworks.com/). Il permet entre autres de compiler en environnement contrôlé, de faire passer des tests unitaires plus spécialisés que sur les postes de développement ou encore de gérer les releases des projets.

Ce service est accessible via l’URL : http://ci.civikey.invenietis.com/

Cruise Control  génère aussi la documentation type MSDN pour chaque release taguée du projet. Elles sont disponibles ici : http://help.civikey.invenietis.com/.

Un deuxième autre post sera dédié à la gestion de Cruise Control par rapport à la gestion des releases.