Côté intégration continue, quelques motifs de fierté…
Dans la pratique, l’intégration continue peut susciter quelques fiertés légitimes. En général, la fameuse PIC (Plateforme d’Intégration Continue) est en place et les développeurs prennent l’habitude d’en tirer le meilleur parti pour intégrer leur travail dans un cadre collaboratif. Leurs travaux sont buildés, testés unitairement, packagés puis placés dans un référentiel avec un niveau d’automatisation qui fluidifie grandement toute cette chaîne. En revanche, le déploiement continu est beaucoup moins bien maîtrisé et certaines pratiques de déploiement en sont encore très éloignées.
Côté déploiement continu, la situation s’avère plus… délicate
Première raison, contrairement à l’intégration continue, le déploiement continu ne se limite pas aux développeurs. Et pour cause : avant d’arriver en production, les packages qui sortent de la PIC vont devoir transiter à travers de nombreux environnements au fil des tests fonctionnels, d’intégration, de sécurité, de performances. Ces environnements sont opérés et maîtrisés par des profils et compétences variés. Sans surprise, la collaboration s’avère forcément plus délicate.
Le déploiement continu cherche encore sa plateforme unique, fédérée…
Seconde raison, là où la PIC bénéficie de solutions globales ou fédérées, le déploiement continu cherche encore sa plateforme, celle capable d’automatiser de bout en bout l’ensemble des étapes : provisioning de l’infrastructure, configuration et déploiement des applicatifs.
À défaut, chacun travaille pour l’heure dans son coin, selon ses propres recettes. Avec des effets de bord bien tangibles à l’instar de cette entreprise qui estime à 3 mois le délai minimum pour déployer un nouveau service de Business Intelligence. Explications : plusieurs équipes sont impliquées (équipe BI, équipe serveur d’application, équipe bases de données, équipe SSL) qui obéissent chacune à leurs propres process et planning…
8 principes pour aller au bout de la démarche DevOps
Problème : les métiers, eux, ne peuvent plus vraiment attendre que la DSI veuille bien ouvrir une fenêtre de tir pour mettre à jour un service. La Transformation Numérique impose bien évidemment un tout autre rythme. Comment avancer concrètement ? Comment aller au bout de la démarche DevOps en s’attelant au chantier du déploiement continu ?
Pour y parvenir, en tout cas pour s’engager sur la bonne voie, voici 8 principes que nous nous efforçons d’appliquer lors de nos missions :
- S’appuyer sur des processus de déploiement fiables et reproductibles
- Se montrer capable d’industrialiser les processus en les automatisant
- Tout versionner (vraiment tout)
- S’attaquer aux tâches les plus pénibles… en premier
- Améliorer la qualité des livrables
- Considérer que le travail est achevé seulement quand le déploiement est effectué
- Veiller à ce que tout le monde se sente responsable, du début à la fin
- Considérer que l’amélioration doit être continue (lien avec chronique DevTestOps)
Précision sur le principe #4. Ainsi formulé, il peut surprendre mais son application est cruciale. Il s’agit finalement de considérer qu’une tâche est d’autant plus pénible qu’on l’exécute rarement. La traiter en priorité, c’est se contraindre à penser comment la régulariser et l’automatiser. Donc c’est aussi simplifier et limiter les risques d’erreur.
Jusqu’à quel point les conteneurs vont-ils changer la donne ?
Dans tous les cas, appliquer réellement ces principes demande ténacité et rigueur en attendant… que les conteneurs changent la donne. Car, moyennant l’ajout d’une couche d’abstraction, ces deniers promettent de nous épargner les fastidieuses tâches de configurations des packages pour les différents environnements. Une perspective qui rendrait du coup caduque la notion même de déploiement continu. Un mythe ? Nous en reparlerons donc très vite ici même…
