DevOps et Continuous Delivery sont les actuels mots à la mode (buzzword pour les anglophones). Après quelques lectures et présentations, certains décideurs se posent la question de l’inflexion vers de telles méthodes. Il faut bien comprendre que derrière ces mots se cache une révision complète des DSI. C’est la fin des fameux silos enfermant chacun dans une mono-tâche technicienne au profit d’un flux automatique organisé par des experts. D’aucuns disent que ce bouleversement est un tsunami, voire un big bang. Il est donc naturel que certains responsables se demandent : Comment opérer à un tel virage vers le Continuous Delivery ?

Cet article orientera vers des perspectives de réponses. Et pour cela, citons d’abord Martin Fowler, un ponte du Continuous Delivery :

You’re doing continuous delivery when:

• Your software is deployable throughout its lifecycle

• Your team prioritizes keeping the software deployable over working on new features

• Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them

• You can perform push-button deployments of any version of the software to any environment on demand

Cycle de vie

Le premier point est celui du déploiement au travers d’un cycle de vie. Il est plus que probable que ce soit déjà le cas. Que ce soit des solutions maison, opensource ou du marché, vous disposez vraisemblablement déjà d’un cycle de vie.
Si ce n’est pas le cas, ou si vous ne voyez pas de quoi il s’agit, c’est que vous êtes sans doute dans une situation de départ vierge, et donc aucune adaptation ne sera nécessaire puisque pour caricaturer vous partez de rien.

Déployable immédiatement

Le premier pavé de la grande route vers le Continuous Delivery à poser est de rendre déployable le logiciel. Et ce avec le souci de l’immédiateté. Il faut qu’à tout moment on puisse déployer sans contrainte. Fini les « attends je vérifie ci et ça » ou « je ne me souviens plus attends je cherche ». Tout doit être préparer en amont dans des scripts et autres processus automatiques. Vos experts doivent border et envisager tous les cas pour produire une belle mécanique de déploiement.
Le but est simple : supprimer toute action manuelle, facteur de perte de temps et d’éventualité d’erreur ou d’oubli.

Il faut relier les étapes, les enchainements de scripts doivent être intégrés dans un méta-script, voire dans un ordonnanceur. Si des vérifications doivent être effectuées (en base, dans des historiques, etc.) il faut les intégrer dans votre déploiement. Si des cas d’exception sont à gérer il faut imaginer à les supprimer ou prévoir des étapes spécifiques.

Et c’est donc avec cette stratégie du zéro action manuelle qu’il faut faire évoluer vos outils de déploiements, au fur et à mesure.

Sans qualification

Un des points clef est qu’une fois votre mécanique en place, il n’y ait plus besoin de qualification pour déployer. Vous devez pouvoir déployer même si votre unique administrateur est absent. Il faut aussi résorber les cassures qui impliquent de faire appel à une autre équipe. Et pour ça, il faut que les différentes équipes collaborent dans une même optique.

En exemple concret : Une équipe de production procède à l’automatisation de son périmètre, jusqu’à un point qui implique les administrateurs de bases de données. Les deux équipes collaboreront pour intégrer la partie base de données jusqu’à ce que l’équipe de production ne doive plus avoir à les solliciter lors des déploiements. Puis l’équipe de production fera de même avec les administrateurs WAS, et ainsi de suite…

Une méthode qui ne relève pas du big bang est la tâche d’huile. De proche en proche, équipe après équipe, vous intégrerez vos « morceaux » de déploiement dans une grande mécanique.

Toute version sur tout environnement

Le dernier point et non des moindres est que vous puissiez déployer n’importe quelle version sur n’importe quel environnement.
Il faut donc pouvoir construire une version ou déposer l’image d’une version, et donc prendre le soin de les stocker et référencer.
Un des corolaires est qu’il ne faut pas se placer dans une stratégie de mise à jour par rapport à une version, mais bel et bien dans une stratégie d’installation d’une version.

La gestion des versions est pleinement une des parties de vos outils de déploiement, et non un à-côté. Il faut intégrer la gestion des versions à votre déploiement.

Source : http://martinfowler.com/bliki/ContinuousDelivery.html