grimboite/old/2012-04-19-jenkins.md

4.8 KiB

Title: Configuration de Jenkins avec des projets .Net 4.0

Installation et configuration de Jenkins

Jenkins est un environnement d'intégration continue développé en Java et qui tourne sur a priori n'importe quel serveur. Après l'installation, Jenkins sera installé et configuré pour tourner en tant que service. Niveau maintenance, la plupart des mises-à-jour et des plugins sont installables directement via l'interface Web.

L'idée:

* Installer Jenkins sur une machine accessible (ie. on y a les droits administrateur, ou au moins de quoi y faire tourner un service/programme, et accès à un répertoire de travail).
* Installer git sur cette même machine, afin que Jenkins puisse cloner des dépôts locaux/distants pour les compiler.
* Installer le plugin [Git](https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin) sur Jenkins (go to 2, pour ceux qui ne suivent pas)
* Installer le plugin [MSBuild](https://wiki.jenkins-ci.org/display/JENKINS/MSBuild+Plugin), toujours sur Jenkins, afin de pouvoir lancer une compilation .Net.

Git

L'installation de Git sur le serveur se fait de manière classique. Il faut cependant se rendre par la suite dans la configuration de Jenkins pour lui indiquer où trouver l'executable. Cette option se trouve dans Jenkins > Administrer Jenkins > Configurer le système > Git installations.

Sur un environnement Windows (je n'ai pas testé sur les autres environnements...), évitez d'avoir des espaces dans le chemin de configuration du dépôt Git (aussi bien bien pour le dépôt distant que pour le répertoire dans lequel le clone sera exécuté). Pour cela, rebelotte: Jenkins > Le projet concerné > Configurer > Options Avancées du projet, et spécifiez-y un répertoire de travail personnalisé.

Pour configurer le planning, la syntaxe suivie est celle de cron:

  • 0 8 * * * lancera un check du dépôt Git tous les jours à 8h du matin.
  • 0,30 * * * * afin d'avoir un check du dépôt toutes les demi-heures.
  • Si le dépôt n'a pas changé entre deux vérifications, la construction du projet ne sera pas exécutée.

Notez que Jenkins fait les choses suffisament bien que pour alerter l'utilisateur si le planning semble mal configuré :)

Idée: configurer le planning sur 0,30 * * * * afin d'avoir un check du dépôt toutes les demi-heures.

MSBuild

Tout d'abord, il vous faut un bidule qui permette de compiler du .Net: MSBuild ou Mono. Il faut ensuite se rendre dans la configuration de Jenkins et lui spécifier un nouveau compilateur: Jenkins > Administrer Jenkins > Configurer le système > MSBuild.

Il faudra ajouter une nouvelle entrée, lui spécifier un nom, puis le chemin vers MSBuild (normalement C:\Windows\Microsoft.Net\Framework\v4.0...\MSBuild.exe).

Dans le paramétrage du projet en lui-même, il faudra également spécifier le chemin vers le fichier .sln à compiler: ce paramètre se trouve dans la section Build, dans le champ MsBuild Build File. Profitez-en pour activer le trigger 'Scruter l'outil de gestion de version'.

Publication ASP

Tant que nous y sommes, autant publier les fichiers sur un serveur IIS si la compilation a réussi. Cela permettra d'avoir un serveur de test constamment à jour. Pour y arriver, il y a plusieurs possibilités:

  • Soit passer par les plugins Jenkins (FTP, SMB, etc.)
  • Soit publier directement sur le bon serveur, avec un path UNC. Pour cela, le mieux est de copier directement les fichiers depuis la command line:
    • rd /S /Q <le_chemin_vers_le_répertoire_de_publication>
    • copy/xcopy/cp/toussa <chemin_initial> <le_chemin_vers_le_répertoire> /E /R /I /K /Y (voir la doc pour les options utiles/inutiles).

Configuration du serveur SMTP

Pour info, c'est une mauvaise idée d'utiliser un serveur SMTP externe: puisque la quantité de mails envoyés par Jenkins risque de passer très rapidement dans les spams :)

Problèmes rencontrés

  • error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.: Deux solutions pour ce problème:
    • soit installer Visual Studio sur la machine de build
    • soit copier toutes les .dll référencées sur la machine distante. Ces fichiers référencés par $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets se trouvent normalement dans le dossier C:\Program Files\MSBuild\*.
  • Git can't clone repository: S'il s'agit d'un chemin UNC, remplacer les backslashes par des slashes pourrait résoudre le problème. \\server\unc_share\folder => //server/unc_share/folder.