Dans de nombreuses équipes de développement, déployer c’est livrer des fonctionnalités aux utilisateurs. Pourtant, il est tout à fait possible de dissocier déploiement et livraison. Cela peut même avoir de nombreux avantages.
Voir la publication originale
Cette dernière est republiée ici afin de ne pas dépendre entièrement d'une plateforme tierce.
Déployer du code est un acte technique: on dépose du code sur un serveur. Livrer une fonctionnalité est un acte produit: on ajoute ou modifie le fonctionnement de l’application pour les utilisateurs.
Dissocier les deux, c’est permettre de déployer fréquemment sans impact utilisateur (ou de manière limitée). C’est pouvoir choisir quelles fonctionnalités livrées et à quel moment. C’est aussi activer une fonctionnalité de manière progressive afin d’observer son impact, ses conséquences en utilisation réelle et ainsi pouvoir relever les éventuels problèmes sur un panel restreint.
Pour que cela se fasse dans de bonnes conditions, il est essentiel de ne pas basculer l’ensemble des utilisateurs d’un coup, mais d’exposer les changements progressivement. On mesure et on ajuste.
Cela permet aux équipes de développement de limiter les développements longs en mode tunnel. On peut alors mettre en place des itérations courtes et déployer des changements incomplets. La fonctionnalité finale ne sera activée qu’une fois complètement terminée ou dans un état réellement utilisable par les utilisateurs finaux.
C’est ainsi que se met en place une stratégie de “Continuous Delivery”. Avoir un code qui soit toujours livrable en production sans accumuler plusieurs semaines de développement. Le déploiement ne doit pas un événement redouté: c’est une opération contrôlée, dont le risque est modéré et facilement réversible ou corrigible.
