DailyBuild d'un projet Delphi avec R2Build

TridenT

Ce tutoriel a pour objectif de vous guider dans la création d'un build automatique pour un projet Delphi avec R2Build. Commentez

- Titre : DailyBuild d'un projet Delphi avec R2Build

- Auteur : TridenT

- Parution : 31 juillet 2009

- Mise à jour : 19 décembre 2019

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2009 TridenT. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- I-A. Pourquoi cet article ?

- I-B. Pourquoi un DailyBuild ?

- I-C. Choix de l'outil R2Build

- I-D. Pourquoi pas un outil d'intégration continue ?

- II. Prérequis

- III. Création du DailyBuild

- III-A. Création d'un répertoire de build

- III-B. Récupération du code source

- III-C. Patch du projet de test

- III-D. Compilation du groupe de projets

- III-E. Exécution des tests

- III-F. Création du livrable

- III-G. Mise à disposition du livrable

- III-H. Nettoyage

- III-I. Incrément de la version du build

- IV. Conclusion

- V. Remerciements

I - Introduction

I-A - Pourquoi cet article ?

Lors du développement de l'outil DelphiCodeToDoc, j'ai eu besoin d'utiliser R2Build pour définir et exécuter des Builds automatiques. Je me propose ici de vous faire part de mon expérience, en vous guidant pas à pas.

I-B - Pourquoi un DailyBuild ?

Pendant le développement de DelphiCodeToDoc, j'ai eu besoin de produire et de mettre à disposition de tous, tous les jours, la version la plus récente du logiciel. Ainsi, les utilisateurs ne sont pas obligés d'attendre une version officielle pour l'essayer ni de recompiler eux-mêmes l'application finale.

Pour produire cette version, j'ai commencé par faire manuellement quelques opérations :

- exporter la version de subversion (outil de versionning) ;

- compiler l'application ;

- compiler les tests unitaires ;

- lancer les tests (unitaires) automatisés ;

- faire un package du livrable ;

- envoyer ce livrable sur mon site FTP.

Tout cela représente ce que l'on nomme couramment un Build. Ils se nomment DailyBuild (ou NightlyBuild) lorsque cette opération est automatisée chaque jour (ou chaque nuit).

I-C - Choix de l'outil R2Build

Pour mon besoin, je voulais utiliser un outil simple, gratuit et open source (comme DelphiCodeToDoc) et ouvert aux extensions (plugin). En tapant les mots-clés Dailybuild et Delphi dans Google, j'ai trouvé R2Build à la deuxième place. Je ne me suis pas posé plus de questions ;)
La page d'accueil de R2Build se trouve ici : http://r2build.sourceforge.net

I-D - Pourquoi pas un outil d'intégration continue ?

Certains d'entre vous s'étonneront peut-être que je n'aie pas utilisé un outil d'intégration continue complet, comme CruiseControl.NET (CC.NET).
La réponse est aussi simple que l'est le besoin : seulement un dailybuild, pas de contrôle particulier, pas de statistiques ni de graphiques, pas de notification, etc.
J'ai plusieurs autres projets inclus dans une architecture d'intégration continue avec CC.NET, mais le besoin est bien plus large.

II - Prérequis

Pour reproduire exactement les étapes de ce petit tutoriel, il vous faut les éléments suivants

- installer R2Build - lien vers le programme d'installation ;

- avoir Delphi 2007 ou 2009 installé ;

- installer le client subversion en ligne de commande - je vous recommande SlikSVN ;

- installer 7Zip - lien vers le programme d'installation ;

- un projet à compiler accessible sous subversion - (DelphiCodeToDoc par exemple).

Le client TortoiseSVN ne contient pas le client SVN en ligne de commande ! Il faut donc installer une version spécifique en ligne de commande comme SlikSVN par exemple.

C'est tout ce qu'il nous faut pour commencer pas à pas le tutoriel.

III - Création du DailyBuild

Nous allons maintenant créer pas à pas notre projet de DailyBuild dans R2Build.

Pour commencer, lançons l'interface de création de projets R2Build.exe (Un nouveau projet vide est automatiquement créé).

III-A - Création d'un répertoire de build

La première chose dont nous avons besoin, c'est de créer un répertoire temporaire où nous ferons toutes nos opérations.

Posons donc un composant Create Dir(s) de la palette File Operation.

Plutôt que de donner le nom du chemin en dur dans ce composant, nous allons éditer une variable qui nous servira tout au long du projet.
Pour cela, Project Setting > Setup Variable onglet Global Var et cliquer sur l'icône ajouter (le signe '+').

Variable_BUILDDIRECTORY

Nous pouvons maintenant double-cliquer sur le composant Create Dir(s) et remplir le paramètre du dossier à créer, c'est-à-dire la variable $BUILDDIRRECTORY

CreateDir_parameters

Pour que cette étape soit la première du script…

Vous pouvez exécuter l'étape sélectionnée en cliquant sur le bouton Run et voir le résultat de l'opération dans la fenêtre de log.

III-B - Récupération du code source

Nous allons maintenant poursuivre en faisant l'opération de checkout du code source, c'est-à-dire le redescendre du gestionnaire de versions.

Le code source de DelphiCodeToDoc est disponible sous Subversion, posons donc un composant Subversion Checkout de la palette Version control system.

La configuration de cette étape est plutôt simple, car nous allons faire un checkout anonyme de la dernière version comme mentionné dans la page d'accueil de DelphiCodeToDoc.

Paramètres du bloc

- URL : http://dephicodetodoc.svn.sourceforge.net/svnroot/dephicodetodoc/trunk/DelphiCodeToDoc

- Destination : $BUILDDIRECTORY\DelphiCodeToDoc

- Les autres champs sont vides

SubversionCheckout_Parameters

III-C - Patch du projet de test

Avant de compiler tout le projet, nous devons forcer la compilation des tests unitaires sous forme de ligne de commande. Sinon, nous aurions une version avec l'IHM de DUnit et il faudrait lancer les tests à la main.
Le projet de test de DelphiCodeToDoc contient, en plus de DEBUG et RELEASE, une configuration appelée CmdLine qui produit une version ligne de commande des tests. Pour forcer cette configuration, il suffit de modifier dans le fichier *.dproj la configuration active.

Pour changer de configuration, nous posons un composant Edit File de la palette File Operation.

Pour configurer cette étape, nous devons fournir les éléments suivants :

- nom du fichier à patcher. Nous sélectionnons le fichier DelphiCodeToDoc_Tests.dproj ;

- la chaîne recherchée dans le fichier, qui contient la configuration Debug ;

- la chaîne de remplacement, avec la nouvelle configuration CmdLine.

EditFile_Parameters

III-D - Compilation du groupe de projets

Maintenant que nous avons le code source, il faut le compiler.
Depuis Delphi2007, les projets *.dproj sont au format MSBuild, ce qui nous simplifiera la tâche !

Posons cette fois le composant MSBuild de la palette Compile System.

La configuration de ce bloc est simple : Target (cible) sera l'action Make, et le projet à compiler $BUILDDIRECTORY\DelphiCodeToDoc\DCTD_and_Tests.groupproj

MSBuild_Parameters

Pour que MSBuild trouve le compilateur Delphi ainsi que sa configuration, il faut créer une variable d'environnement pour ce composant MSBuild.
Sélectionner le composant MSBuild, cliquer sur Menu > Project Setting > Setup variable, Onglet MSBuild Var.

Configuration de la nouvelle variable :

- Name : BDS ;

- Value : C:\Program Files\CodeGear\RAD Studio\6.0 ;

- Environment variable : Coché

Variable_BDS

III-E - Exécution des tests

Avant de faire le package final, nous devons être sûrs que les tests unitaires et d'intégration passent tous.
Nous allons donc exécuter les tests précédemment compilés sous forme d'application console.

Nous posons un composant Custom command de la palette Build in functions.

C'est une exécution de commande DOS simple, avec les mêmes paramètres qu'un raccourci Windows.
Si les tests échouent (quelle qu’en soit la raison), le code de retour indiquera une erreur.

DUnit_Parameters

III-F - Création du livrable

Maintenant que nous avons créé l'exécutable, nous pouvons créer le package, ou le livrable, que nous voulons.
Pour DelphiCodeToDoc, je voulais aller au plus simple et zipper l'exécutable uniquement.
Pour réaliser cela, nous allons d'abord créer un sous-répertoire de travail pour la création de notre livrable.

Posons donc un composant Create Dir(s) de la palette File Operation.

CreateDir2_parameters

Posons ensuite un composant 7-zip archive de la palette File Operation.

Nous devons ajouter les éléments suivants :

- le nom de l'archive : $BUILDDIRECTORY\dailybuild\DelphiCodeToDoc.zip ;

- le fichier à compresser : $BUILDDIRECTORY\DelphiCodeToDoc\Exe\DelphiCodeToDoc.exe.

7zip_Parameters

III-G - Mise à disposition du livrable

Posons ensuite un composant FTP Upload files de la palette Network.

FtpUploadFiles_Parameters

III-H - Nettoyage

Le nettoyage va consister à supprimer notre répertoire temporaire de build.
R2Build permet de faire cette opération à partir de deux composants.

Le premier sera le composant Delete files de la palette File operation.

DeleteFiles_Parameters

Cette étape supprimera tous les fichiers de notre arborescence.

Le second sera le composant Delete dir de la palette File operation.

DeleteDir_Parameters

Cette étape supprimera tous les répertoires de notre arborescence.

L'emploi de ces deux commandes vide complètement notre répertoire de build, et ne laisse aucune trace.

III-I - Incrément de la version du build

Pour finaliser notre Build, nous allons incrémenter le numéro de version du build pour garder un historique des versions.

Posons un composant Edit Variable de la palette Build in functions.

EditBuildNumber_Parameters

IV - Conclusion

Avec ces étapes réalisées, nous avons maintenant une feuille de Build qui devrait ressembler à cela :

R2Build_DelphiCodeToDoc

Ce script peut ensuite être lancé de manière automatisée avec l'application R2Build Dashboard, toutes les nuits par exemple.

Pour compléter cet exemple, il serait possible et souhaitable de :

- injecter le numéro du build dans le nom du livrable créé ;

- créer un installeur pour le livrable ;

- gérer les erreurs de chaque bloc ;

- envoyer un mail en cas de problème du build ;

- générer de la documentation automatiquement à partir du code.

J'espère que ce petit tutoriel vous aura donné envie d'essayer ce logiciel bien pratique.
N'hésitez pas à me contacter si vous avez des questions ou des idées d'amélioration.

V - Remerciements

Merci à Bovino pour la relecture de cet article.
Merci aussi à Ricky81, Progi1984 et Nono40 pour leur aide.