FLASH INFORMATIQUE FI



Déploiement continu, cas du moteur de recherche de l’EPFL


Voici quelques principes de déploiement continu et leur application aux processus de développement du moteur de recherche de l’EPFL.


We introduce here some principles of continuous delivery and we present their application to the development process of the EPFL search engine.


Maciej MACOWICZ


Cycle de vie d’une application

Le cycle de vie d’une application informatique commence par la phase de définition et analyse des besoins, suivi de la conception ; dans la phase de codage on élabore les codes sources de l’application. Les tests permettent de trouver des erreurs techniques ou fonctionnelles ; ensuite, lors du déploiement on installe l’application sur les serveurs de production. Finalement la maintenance consiste à corriger des erreurs ou à ajouter des nouvelles fonctionnalités selon les besoins identifiés ; les concepteurs de l’application repassent alors par les phases de conception, de codage, refont les tests, et finalement déploient en production. Les principaux problèmes liés au cycle de vie d’une application sont :

  • les différentes activités (construction de l’application, tests, mise en production, etc.) souvent effectuées à la main ; nécessitant un savoir-faire particulier et pouvant conduire à des erreurs,
  • les environnements de test différents de ceux de production ; par conséquent certaines erreurs se manifesteront en production sans avoir pu être détectées pendant les tests,
  • la mise en production manuelle et fastidieuse et demande beaucoup d’efforts. Elle intervient donc rarement, privant les utilisateurs finaux des corrections ou améliorations durant une longue période,
  • l’installation manuelle de nouveaux serveurs pour l’application présente un risque accru, car elle est fastidieuse et demande un savoir-faire très particulier.

Déploiement continu

Les pratiques de déploiement continu [1] sont apparues pour pallier ces problèmes, minimiser la distance entre les phases et permettre les mises en production de la manière la plus rapide et la plus efficace possible tout en minimisant les risques. Le terme continu signifie qu’une nouvelle version de l’application peut être déployée à tout moment, le terme déploiement se réfère à la mise en production d’une nouvelle version de l’application à partir des codes sources, mais aussi à l’installation d’un nouveau serveur pour l’application à partir des configurations nécessaires.
Le déploiement continu s’appuie sur différents principes :

  • les tâches répétitives (construction des exécutables, reconfiguration des serveurs, mise en production, tests, ...) sont automatisées et effectuées par des scripts,
  • les données utilisées pour la construction (codes sources, scripts) et le fonctionnement de l’application (configurations des serveurs, des logiciels tiers, de l’OS) sont stockés dans un dépôt permettant la gestion de versions,
  • l’application est accompagnée d’une suite de tests automatisés, qui détectent les erreurs techniques et fonctionnelles,
  • les serveurs de production sont accompagnés de serveurs de test de configuration identique,
  • le déploiement sur les serveurs de test et de production se fait exclusivement par les scripts, les opérations manuelles sont limitées au strict minimum,
  • la création d’un nouveau serveur de test ou de production est entièrement automatisée, toutes les informations nécessaires sont disponibles dans le dépôt.

Du point de vue du développeur le déploiement continu n’a rien de révolutionnaire, c’est juste un recueil de bonnes pratiques basées sur des règles de bon sens. Nous allons présenter l’application de ces principes au moteur de recherche de l’EPFL, search 2010.

Environnement de développement de search 2010

Search 2010 est une application mixte J2EE/Groovy, déployée sur deux serveurs physiques de production, placés derrière le répartiteur de charge. L’environnement de développement de search2010 est construit conformément aux recettes de déploiement continu et comporte : un poste de développement, les serveurs de construction et de test et les serveurs de production. La plupart des tâches (construction/test/déploiement) sont automatisées par des scripts ; un dépôt est utilisé pour les codes sources, les scripts et les configurations des serveurs.
Le poste de développement comprend les exécutifs Java et Groovy, un environnement de développement pour élaborer les codes sources, les outils de construction nécessaires (maven et gradle), un gestionnaire de versions (svn) pour accéder au dépôt, une version allégée de serveur d’application (tomcat) pour pouvoir exécuter l’application sans avoir à la déployer, et l’environnement Geb [2]/Selenium [3] pour effectuer des tests fonctionnels (par simulation du comportement de l’utilisateur face à un navigateur Web). On peut enregistrer les modifications des codes sources dans le dépôt uniquement depuis le poste de développement.
Le serveur de construction est utilisé pour construire l’application à partir de codes sources rapatriés depuis le dépôt et pour la déployer (automatiquement, par script) sur les serveurs de test et/ou de production. Il comporte un gestionnaire de versions, un outil de construction et les scripts de construction/déploiement, qui peuvent être modifiés sur ce serveur et stockés dans le dépôt. Les serveurs de test sont utilisés pour tester l’application dans un environnement identique à la production. Ils comportent un gestionnaire de versions et un serveur d’application (apache et tomcat). L’application est déployée sur les serveurs de test depuis le serveur de construction, les tests fonctionnels se font alors depuis le poste de développement. Les serveurs de test peuvent également servir pour démonstration d’une nouvelle fonctionnalité de l’application dont le développement n’est pas terminé (depuis une branche particulière du dépôt).
Toute modification des configurations du serveur d’application (apache et tomcat) ne peut se faire que sur les serveurs de tests et est stockée dans le dépôt.
Les serveurs de production comportent un gestionnaire de versions et un serveur d’application ; aucune modification de l’application ni des configurations n’est possible. L’application est déployée depuis le serveur de construction, les configurations sont rapatriées depuis le dépôt.


processus de développement/déploiement de search 2010

Il y a trois phases principales du développement (voir schéma) :

  1. Le développement proprement dit se passe sur le poste de développement, le développeur a la possibilité de modifier les codes sources, construire et exécuter l’application en local et lancer une suite de tests en local. Une fois un jalon de développement (correction d’une erreur ou mise en place d’une fonctionnalité) atteint, on envoie les sources dans le dépôt et on passe à la phase de tests.
  2. Les tests ont lieu entre le poste de développement et les serveurs de construction et de test. Durant cette phase on rapatrie les sources depuis le dépôt sur le serveur de construction, on construit l’application et on la déploie sur les serveurs de test. Ensuite on lance les tests automatisés des serveurs de test depuis le poste de développement. On repasse en développement si les tests échouent, sinon on passe au déploiement. Dans cette phase on a la possibilité de modifier les configurations du serveur d’application.
  3. Le déploiement a lieu entre les serveurs de construction et de production ; cette phase consiste à déployer l’application construite et testée dans la phase précédente sur les serveurs de production. Il est également possible de lancer les tests fonctionnels depuis le poste de développement.

L’installation d’un nouveau serveur de construction/test/production (smoke-test) est entièrement automatique, on commence par installer le système d’exploitation, on le configure suivant les recettes gérées par le système Puppet et stockées dans le dépôt. Ensuite on rapatrie depuis le dépôt le script d’installation de search.epfl.ch, qui à son tour transfère les configurations du serveur d’application et l’exécutable de l’application. Le nouveau serveur est alors prêt à l’emploi. L’installation d’un nouveau poste de développement est plus fastidieuse et nécessite le rapatriement manuel de la plupart des logiciels utilisés ; bien documentée, elle peut cependant se faire en moins de deux heures de travail.

Conclusion

Le processus de développement de search 2010 présente des avantages indéniables :

  • disponibilité de modifications en production juste après la fin de leur élaboration,
  • possibilité de démonstration des fonctionnalités en cours de développement (depuis une branche du dépôt) sans effort (déploiement sur les serveurs de test),
  • tests effectués dans un environnement de test identique à la production, donc pertinents,
  • répétabilité et prédictibilité de processus de développement/déploiement,
  • possibilité de reconstruction rapide de serveurs.

Vu la taille du projet search 2010 (un seul développeur), nous n’avons pas jugé utile d’installer un serveur d’intégration (par exemple Jenkins [4].) pour automatiser les phases de développement.

[1] HUMBLE, Jez and FARLEY David. Continuous Delivery : Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Signature Series (Fowler), 2011.

[2] Geb : very groovy browser automation

[3] Selenium Browser Automation

[4] Jenkins : An extendable open source continuous integration server



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.