DevOps : 8 principes pour s’attaquer au chantier du déploiement continu

7/04/2017

Une étude le confirmait encore tout récemment : en France les responsables IT montrent un grand intérêt pour la démarche DevOps. De fait, la formation des équipes comme l’adoption d’un outillage adéquat figurent en bonne place dans la feuille de route des directions des Systèmes d’Information. Mais cette perception s’apparente à celle du verre à moitié plein…

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…

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptée aux besoins et au SI existant de votre entreprise.

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures...

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.