L'intégration continue (IC) est un processus dans lequel software en cours de développement est continuellement compilé et testé au fur et à mesure que les modifications sont soumises à un système de contrôle des révisions. L'objectif est d'identifier les problèmes tels que les changements de code qui interrompent la compilation, les tests unitaires et les tests fonctionnels interrompus, dès que possible après l'introduction d'un tel changement. En identifiant ces problèmes plus tôt, ils sont résolus plus rapidement, ce qui réduit l'impact sur l'ensemble de l'équipe. Dans une méthodologie de développement Agile Software , ce type de retour d'information immédiat est essentiel pour qu'une équipe atteigne ses objectifs itératifs.
La mise en place d'un environnement de CI se compose de plusieurs parties :
- Machine de construction dédiée
- Intégration continue software
- Constructions automatisées et reproductibles
- Tests unitaires et fonctionnels automatisés
CSS utilise un processus d'intégration continue pour tous ses efforts de développement software .
Une machine de construction dédiée et autonome sert de "salle blanche" pour la construction des produits software . Cette machine est un environnement contrôlé, les nouvelles software et les mises à jour n'ayant lieu que lorsque notre calendrier de développement le permet. Les machines de construction sont souvent installées dans un environnement virtualisé, ce qui facilite leur extension et leur permet d'être à l'épreuve du temps si une capacité plus importante est nécessaire à l'avenir.
La deuxième partie est le serveur CI lui-même. Il existe plusieurs systèmes de CI commerciaux et open-source , notamment Jenkins, Microsoft TFS, Atlassian Bamboo, Cruise Control, Cruise Control.NET et bien d'autres. Le serveur CI est responsable de la gestion du flux de travail de votre processus CI. Il peut être déclenché pour construire un produit software manuellement, sur une base temporelle (Nightly Builds), ou sur une base de changement en surveillant continuellement votre système de contrôle de révision à la recherche de changements de la part des développeurs. Les serveurs CI exécutent vos tests unitaires et analysent les résultats pour déterminer l'état de santé d'une compilation. La plupart des serveurs CI peuvent être configurés pour archiver les artefacts de compilation (binaires, installations et symboles) après une compilation réussie.
La troisième composante est l'automatisation de la construction. Une construction entièrement automatisée profite à la fois au processus de CI et à l'équipe de développement. Idéalement, le même système de construction automatisé est utilisé par les développeurs et le serveur CI. Un développeur ne devrait avoir à installer que quelques pré-requis sur sa machine (comme Visual Studio). Le script de construction devrait se charger de télécharger les dépendances nécessaires (internes et externes) avant que la construction du code source ne commence.
La dernière partie d'une installation d'IC (et une bonne pratique de développement même sans IC) est l'automatisation des tests unitaires et fonctionnels. S'il est bon de savoir qu'un ensemble de modifications apportées au produit va se compiler, il est encore meilleur de savoir qu'elles n'ont pas cassé la fonctionnalité. Ce qui est encore mieux, c'est que cette vérification s'effectue sans aucune action de la part d'un développeur, ce qui permet à ce dernier de se concentrer sur la création de fonctionnalités pour le produit.
Le processus d'IC en action au CSS
Notre processus d'intégration continue se déclenche chaque fois qu'un développeur enregistre des modifications dans notre système de contrôle des révisions. Nous utilisons actuellement Jenkins comme serveur d'intégration continue. Jenkins a ses racines dans le domaine Java, mais contient maintenant des centaines de plugins pour étendre ses fonctionnalités. Jusqu'à présent, il a très bien fonctionné pour la construction de nos produits basés sur .NET, ainsi que sur le code natif. Nous sommes également de grands fans du plug-in BruceSchneier pour Jenkins.
L'un des nombreux éléments de Bruce Schneier qui apparaissent dans notre système de construction.
Notre processus de construction existant basé sur MSBuild a facilité la configuration de Jenkins. Tout ce que nous avions à faire était de sélectionner l'URL Subversion pour le projet, et de sélectionner notre script MSBuild, en passant le nom de la cible qui représente la construction CI complète. Nous avons investi beaucoup d'efforts dans notre système de construction basé sur MSBuild. Notre objectif est d'avoir un modèle MSBuild unique que nous réutilisons pour chaque produit, ce qui permet à nos constructions d'être cohérentes et fiables. Notre script MSBuild effectue les tâches suivantes :
- Télécharger les dépendances
- Compilation du code pour le produit
- Les projets de tests unitaires sont construits et exécutés
- L'obscurcissement est appliqué aux résultats de la construction.
- Signature Authenticode des résultats de la construction
- Construire l'installation
- Signature Authenticode de l'installation
- Fichiers de symboles postés sur notre serveur de symboles interne
- Archivage sur notre serveur de fichiers interne
Dès qu'un check-in est détecté, le serveur CI télécharge automatiquement la dernière source du produit. Il lance une compilation de la source et, en cas de succès, continue à exécuter nos tests, à construire les installateurs, à signer numériquement les composants et à publier les artefacts de la compilation sur notre serveur de fichiers interne. 10 à 15 minutes plus tard, nous disposons d'un rapport complet sur la construction, y compris les résultats des tests. Enfin, le serveur CI nous informe (soit par une application de la barre d'état système, soit par courrier électronique) de la réussite ou de l'échec de la compilation.
Processus d'intégration continue en action.
Conclusions
La mise en place d'un bon processus d'analyse critique n'est pas une tâche facile et nécessite plus qu'une quantité nominale de travail pour arriver à la perfection. Bien qu'il y ait un coût initial, les organisations verront sans aucun doute les retombées de leur processus d'IC. Le processus d'IC permet de détecter immédiatement les erreurs de compilation du code source et les échecs des tests unitaires, au lieu de les laisser s'accumuler et entraver la productivité de l'ensemble de l'équipe. L'historique de la compilation, y compris l'historique de l'exécution des tests unitaires, est archivé et accessible via le portail du serveur CI. Un processus d'IC solide permet aux développeurs de continuer à écrire du code, au lieu de se consacrer à des tâches répétitives telles que l'exécution de tests unitaires ou la construction manuelle du produit.
Liens
- Jenkins CI - https://jenkins-ci.org
- Plugins Jenkins - https://wiki.jenkins-ci.org/display/JENKINS/Plugins
- Martin Fowler sur l'intégration continue - https://martinfowler.com/articles/continuousIntegration.html
- Wikipédia : Intégration continue - https://en.wikipedia.org/wiki/Continuous_integration
