Les cookies assurent le bon fonctionnement de notre site. En utilisant ce dernier, vous acceptez l'utilisation des cookies. En savoir plus OK
Vous êtes ici : Accueil / Blog / 2013 / 08 / Intégration et déploiement continus au CIRB

Intégration et déploiement continus au CIRB

De bonnes pratiques pour délivrer plus rapidement les nouvelles releases et les produits phares
des collègues de bureau collaborent ensemble

des collègues de bureau collaborent ensemble

 

Dans le but de délivrer plus rapidement les nouvelles releases de ses produits phares, le CIRB applique les bonnes pratiques de l’intégration et du déploiement continus. Le client obtient plus rapidement la nouvelle fonctionnalité ou le changement attendu dans un environnement de production stable et évolutif.

A partir de 2012, le CIRB a mis en place une équipe interdépartementale qui associe les développeurs (département Projets) et les opérateurs (département Services) au sein d’un cycle de production. Cette équipe à plusieurs objectifs.

Dans un premier temps elle offre un espace pour mettre à plat nos manières de travailler et de collaborer. Les développeurs (Devs) et les opérateurs (Ops) n’ont pas les mêmes intérêts. Les Devs sont valorisés aux changements (features). Les Ops sont les gardiens de la stabilité (uptime). Au sein de cette équipe, chacun peut ouvertement partager ses attentes, prendre conscience de l’intérêt collectif et in fine du client.

Ensuite, l’équipe promeut l’unification, pour ne pas dire la standardisation, de nos outils et de nos environnements de travail. Il s’agit d’une tâche d’évangélisation interne avec laquelle nous renforçons nos acquis et limitons la dispersion. En suivant les orientations du marché et les attentes de nos clients, nous prenons le temps de la réflexion pour évoluer sur base d’arguments objectifs. Nous établissons avec l’aide du management nos niveaux de supports cibles (SLA / OLA).

Sur base de ces a>automatiser les tests (unitaires, fonctionnels, non fonctionnels), le packaging du code, la récolte des métriques relatives à la qualité du code, la génération des releases notes et la promotion de chaque release au travers de la chaîne jusqu’à une éventuelle mise en production. Ceci nous permet de découvrir le plus rapidement possible les régressions dans le processus de développement (souvent dès que le développeur a sauvé son changement dans le gestionnaire de code source). Les erreurs et le temps consacré aux manipulations sont réduits, la qualité s’améliore. Des tableaux de bord offrent une visibilité sur l’état courant du code passé en exploitation. Les modifications apportées au code sont tracées pour chaque changement implémenté.

L’équipe poursuit par la mise en place d’un processus de déploiement continu pour permettre de réduire les manipulations et de ce fait les interruptions de service lors des mises en production. Ce processus permet également d’automatiser la création des serveurs et de rendre invariablement reproductible le déploiement des applications sur ceux-ci. Nous pouvons alors augmenter la fréquence des déploiements, mettre en production des ensembles plus limités de fonctionnalités. L’impact du changement est donc limité. Il est plus facilement testé et accepté. Nous investiguons en outre la mise en place de processus automatisés de migration de données (upgrade/downgrade de base de données) dans et entre les différents environnements (test, production, …)

Finalement l’équipe veille à la mise en place du monitoring applicatif pour récolter des statistiques qui nous permettent d’analyser les performances, d’optimiser les environnements et la qualité du code. Elle veille également à détailler le descriptif des incidents rapportés avant transfert vers le support, aidant à identifier les causes d’erreurs.

Cette chaîne s’appuie sur les outils suivants:

  • GitConfluence et Alfresco afin que tant le code source, les configurations, la vie du projet et les documents soient versionés
  • Jenkins, le serveur d’intégration continue.
  • Sonar, avec lequel nous faisons le suivi de qualité du code
  • Spiratest nous permet de tracer les tests réalisés pour chaque version d’une plate-forme.
  • Puppet, l’outil qui nous permet de déployer nos configurations sur l’ensemble de nos machines
  • Pulp qui nous permet de gérer nos packages
  • SaltStack, outil d’orchestration des machines
  • Jira pour le suivi des taches
  • BSM et Graphite pour le suivi des performances des serveurs et des applications
  • VMWare et Vagrant pour permettre d’automatiser les déploiements tant sur nos fermes de serveurs dans le Data Center Régional que localement sur les ordinateurs des développeurs.

Quelques indicateurs clés nous permettent de mesurer l’évolution des améliorations que nous mettons en place:

  • le temps entre deux changements en production – temps qu’il faut pour qu’un changement soit mis en production;
  • la fréquence de déploiement en production – quantité de déploiement par semaine;
  • le temps nécessaire pour corriger un incident en production;
  • la quantité d’erreurs découvertes en production suite à des changements

La principale avancée est l’amélioration de la communication et la collaboration entre développeurs et opérateurs. Rapidement les équipes de terrain ont adhéré au mouvement.  Chacun avait besoin de donner de la visibilité à ses activités, de les améliorer, de les partager. Le management a embrayé en donnant les moyens d’y parvenir. Appuyé par une équipe représentative de l’ensemble des services du CIRB, la démarche s’inscrit dans un processus d’amélioration continue de la qualité.

Références:

  1. Swartout, Paul (2012-11-01). Continuous delivery and DevOps: A Quickstart Guide
  2. Farley, David; Humble, Jez (2010-07-27). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
  3. http://en.wikipedia.org/wiki/DevOps
Patrick Colmant
Patrick Colmant a écrit :
23/10/2013 09:44

Merci à Godefroid Chapelle, Benoît Suttor, Clément Martin, Pierre Radermecker et Jean-François Roche qui ont aussi contribué à ce post.

Johan De Pessemier
Johan De Pessemier a écrit :
23/10/2013 09:46

Patrick merci pour ce post!
Il démontre le travail effectué depuis quelques années avec la mise en place (comme tu l’indiques très justement – Git, Confluence, Jira, Alfresco, SpiraTest pour ne citer que ceux-là) des outils utilisés dans le département pour améliorer notre manière de travailler et augmenter la qualité des releases livrées à nos clients

Ajouter un commentaire

Vous pouvez ajouter un commentaire en complétant le formulaire ci-dessous. Le format doit être plain text. Les commentaires sont modérés.

Question: Combien font 4 + 4 ?
Votre réponse:

Tous nos posts