Jenkins : Intégration continue et déploiement automatisé

Bien avant l’engouement pour DevOps, le travail itératif était déjà identifié comme une manière efficiente de travailler pour les développements. Grâce à l’intégration continue (IC), les développeurs intègrent notamment des améliorations dès le build régulier automatisé et jusqu’à la livraison continue en production. L’intégration continue est déployée notamment par Jenkins, un outil opensource simple d’utilisation, et extrêmement flexible.

La place de l’Intégration continue

Faire de l’intégration continue, c’est assurer qu’aucune régression du code source ne soit permise par les modifications successives de celui-ci. En pratique, cela se traduit par une mise en commun du travail des développeurs tout au long du projet pour s’assurer que l’application finale soit compatible avec les composants en cours de développement. L’intégration continue constitue un véritable atout pour les projets car les failles sont rapidement identifiées, ainsi leurs corrections peuvent être effectuées à temps. De plus, les tests réguliers, automatisés lors de chaque intégration, permettent de repérer les modifications problématiques. Le versionning de l’application est clair, et la dernière version stable peut facilement être obtenue par de nouveaux tests, ou pour une démonstration.

Les bénéfices de la livraison continue

Objectif satisfaction client avec la livraison continue, dont la seule mission est évidemment de délivrer un logiciel qui offre aux utilisateurs les fonctionnalités, l’ergonomie, la performance et la robustesse demandés initialement. Rien ne serait si évident s’il n’était pas si important de réduire le temps entre la demande et la livraison du nouveau logiciel.

En livraison continue (continuous delivery), on retient 2 axes cruciaux :

  • l’automatisation de la livraison pour un processus de déploiement fiable et sans risque humain
  • la livraison rapide pour une procédure fiable mais principalement pour réduire le temps entre l’idée du projet, sa création et son feedback, afin que tous (métiers et développeurs) soient encore concernés par le projet.

Etapes de mise en œuvre du déploiement automatisé avec JENKINS

Jenkins c’est une application web, développée en java. Ce qui lui confère l’avantage d’être compatible avec plusieurs systèmes d’exploitation. Il est possible de l’installer de plusieurs façons : en web-app, en standalone ou en slave. En pratique, des configurations sont nécessaires au démarrage, notamment pour gérer la sécurité, pour intégrer des outils tiers ou encore ajouter des plugins… Mais la création des jobs, leur distribution et l’interprétation des résultats restent cruciaux.

Dans sa forme la plus élémentaire, le Déploiement Automatisé peut être aussi simple que l’écriture de vos propres scripts afin de déployer votre application vers un serveur particulier. L’avantage principal de la solution scriptée est la simplicité et l’aisance en termes de configuration. Cependant, une telle approche peut atteindre ses limites si vous avez besoin de mettre en oeuvre des actions de déploiement plus élaborées, telles qu’installer un logiciel sur une machine ou redémarrer le serveur.

Le script de déploiement

Une part centrale de tout projet de déploiement automatisé est la mise en place d’un déploiement scripté. Souvent, le déploiement apparait être un processus consommateur de ressources. Pourtant, avec un peu de travail, il est généralement possible d’écrire un script pour automatisé la plupart, voir l’intégralité, du processus.

Mises à jour de base de données

Déployer votre application vers le serveur d’application est la partie la plus visible du projet. Les bases de données sont centrales dans l’architecture logicielle.
Les mises à jour de base de données sont généralement plus difficiles à mettre en œuvre que les mises à jour applicatives, vu que tant la structure que les données sont susceptibles d’être modifiées. Cependant, les mises à jour de base de données sont critiques pour le développement et le déploiement. Elles méritent donc de l’attention et de la planification.

Tests fumigatoires

N’importe quel déploiement automatisé nécessite un suivi par une série de tests fumigatoires automatisés. Les tests fumigatoires devraient être non intrusifs et rapides. Ils doivent pouvoir être exécutés en production, ce qui est susceptible de restreindre le nombre d’actions possibles durant les tests.