Intégration continue – les outils pour commencer

miaffo.net - Intégration continue

Bienvenue dans ce nouveau tutoriel consacré aux outils d’intégration continue.

Je suis Dieudonné MIAFFO, passionné des TIC. Dans ce nouveau tutoriel, je vais vous présenter un ensemble d’outils indispensables pour commencer et mener à bien un projet d’intégration continue.

Déjà pourquoi faire de l’intégration continue au cours d’un projet ? Pour répondre à cette question, commençons par modifier la sémantique de “Intégration continue” pour plutôt parler de l'”Intégration en continue”.  Il s’agit effectivement de faire de façon continue l’intégration tout au long de la mise en œuvre du projet. Pour mieux comprendre, voici les besoins pour les quels on peut être intéressé à se lancer sur l’intégration continue.

Les besoins

  • Accélérer les déploiements
  • Automatiser des tests de non régression
  • Automatiser les déploiement sur les environnements de développement
  • Mettre en place des accélérateurs de développement
  • Rapprocher les équipes de développement et d’exploitation

Les principes

Intégration continue

  • Toute modification effectuée par un développeur et jugée stable est comité dans le gestionnaire des sources.
  • Les modifications sont testées et intégrées dans le branche de développement
  • A tout moment du cycle, le code est testé et le projet prête à être livré.

Ces étapes indispensables permettent de mettre en œuvre une démarche de déploiement continu.

Déploiement continu

  • Le besoin est de livrer en continu les corrections ou évolutions de services. Dans le cadre de l’agilité, la livraison doit être régulière.
  • L’humain doit intervenir le moins possible sur cette phase

Les outils

Un gestionnaire des sources ou de versions (SCM)

  • Il doit permettre de gérer le travail collaboratif
  • Maintenir l’historique des modifications
  • Gérer les conflits sur le code
  • Permettre de créer des branches et des tags associés aux versions de livraison.

Une PIC: Plateforme d’Intégration continue qui va s’interfacer avec le SCM. Il fournira pour des besoins de simplicité une interface graphique pour accéder au SCM et piloter les déploiements.

  • Il permettra d’exécuter des tâches sur le code source,
  • lancer des tests dans les conditions de production (ou presque)
  • Construire les release
  • Contrôlera la qualité du code en envoyant des rapports de régression aux gestionnaires

Les produits

SVN

  • SVN est aussi un des outils puissamment utilisé dans le développement logiciel. C’est le remplaçant de CVS pour ceux qui connaissent cet outil.
  • Il permet de gérer les différentes version d’un logiciel en cours de développement

GIT

  • Contrairement à SVN, GIT est un système de gestion de version distribué avec un serveur centralisé.
  • Permet d’avoir un historique local des sources
  • Les sources locales sont ensuite poussées sur le serveur central
  • Même s’il faut un temps d’adaptation pour la prise en main, la création des branches reste intuitive et facile
  • GitLab CE est souvent utilisé comme interface de gestion des projets GIT et aussi une interface web qui permet de gérer des projets et les utilisateurs.
  • GitLab va aussi permettre de naviguer dans le code source, de suivre les releases, branches et tags.
  • Intégré à GitLab GitLab-CI permet d’exécuter des tests locaux ou distants

Jenkins

  • Jenkins est un outil qui permet d’automatiser les tâches d’intégration continue, à ce titre, il permet de
  • Lancer des tests unitaires
  • Exécuter des scripts
  • Compiler les projets et effectuer les déploiements
  • Jenkins offre la possibilité d’ajouter des plugins
  • Jenkins bénéficie d’une vaste communauté, ce qui rend cet outil populaire

Maven

  • Maven est un outil de « build » qui permet modéliser et « fabriquer » un projet. Il s’agit de toutes les étapes depuis la création du code source jusqu’à la livraison du projet.
  • Permet de gérer le cycle de vie des projets complexes
  • Il permet aussi de gérer de manière cohérente les interdépendances entre différents modules.

Nexus

  • Nexus va jouer le rôle de conteneur des packages. De toutes les archives. Il s’agira principalement des projets compilés en version SNAPSHOT, c’est-à-dire des version stables, et aussi des RELEASE.
  • Les différentes archives peuvent être des package de type, WAR, EAR, JAR …

 

Si vous aimez, laissez moi un commentaire ou envoyez moi un mail si vous voulez plus de précisions.

Dieudonné MIAFFO

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Résoudre : *
13 − 9 =