Menu
Mettre en production son produit est toujours complexe. Le moment où tout le travail combiné des équipes est mis à disposition du grand public est chargé de questions : est-ce que tout va fonctionner comme prévu, comme testé ? Comment les utilisateurs vont-ils réagir au produit ?
Le release management, avec la méthode agile, propose un déploiement continu de ses versions dans le domaine informatique. Cela permet de réduire les cycles de développement, d’avoir des retours utilisateurs rapides, et de s’adapter rapidement aux changements possibles du marché ou aux bugs grâce à des patchs correctifs.
Lors de la mise en production agile d’un produit, il faut commencer par avoir une version basique de ce produit qui réponde aux User Stories les plus prioritaires. Dans le cas de notre exemple d’application qui permet de parcourir les collections des musées, cela serait de trouver des musées autour de soi et de pouvoir filtrer les expositions entre celles temporaires et celles permanentes.
On sort cette application en version dite alpha : c’est le squelette, l’armature sur laquelle il nous sera possible de déployer nos versions suivantes. Dès lors qu’une User Story est validée par le Product Owner, elle peut être mise en production.
Cependant, cette méthode de mise en production demande une vigilance constante. Comment faire pour s’assurer qu’un ajout de fonctionnalités ne va pas déclencher de problèmes ?
Derrière le terme d’intégration continue se cache un concept très simple : éviter les régressions du logiciel ou de l’application. Pour ce faire, on leur fait subir des tests de manière automatique.
Lors de la phase de production agile, seuls les tests automatisés sont permis : tous les tests humains auront dû être effectués auparavant. Si un souci est rencontré lors du déploiement de la nouvelle version, la mise en production sera arrêtée.
Il est primordial de pouvoir effectuer un rollback, un retour à la version précédente, qui était stable. Pour ce faire, il est fortement conseillé d’avoir recours à des outils de versioning qui conservent les versions précédentes de l’application et permettent de maintenir un service, en attendant que les problèmes rencontrés lors du déploiement soient résolus.
Cette sécurité est toutefois complexe à mettre en place, car les tests sont nombreux et prennent du temps. Pour n’en citer que quelques-uns, on retrouve :
La méthode dite du Canary deployment permet de choisir un petit échantillon d’utilisateurs et de leur proposer la nouvelle version d’un logiciel ou d’un produit. Autrefois très complexe à mettre en place, elle est aujourd’hui simplifiée par les environnements clouds, et recommandée pour se faire une idée du ressenti de la mise à jour sur ses utilisateurs à plus petite échelle.
Les autres utilisateurs restent sur la version précédente du produit le temps que les tests soient effectués en situation réelle. Si aucun problème n’apparaît (charge importante sur les serveurs, bugs, incompatibilité des fonctionnalités, etc.), on peut alors mettre en production cette version N+1.
Si cette méthode est très pratique et ne demande que des outils d’observation et d’analyse, elle n’en reste pas moins légèrement complexe à mettre en place. Il faut déjà avoir un public qui s’intéresse à l’évolution de l’application ou du logiciel, et qu’une partie de ce public veuille bien prendre le risque de tester ses évolutions.
Vous pouvez découvrir les différentes techniques de mise en production informatique dans cette vidéo.
En résumé, le secret d’une bonne mise en production agile est sa continuité. Cependant, cela nécessite la mise en place de dispositifs de sécurité tels que le versioning lors des déploiements successifs. Ces sécurités peuvent se faire de manière automatique par intégration continue. Il est également possible de faire des tests finaux d’une nouvelle version du produit sur un petit échantillon de personnes afin de s’assurer que tout est parfait pour la mise en production publique.
