Même si il y a apparemment de bonnes raisons de ne pas forcément vouloir déployer à chaque push, l'argument les plus important pour cette pratique, à mes yeux, suit le plan suivant:
Il faut toujours être en capacité de déployer car on peut avoir besoin de corriger un problème grave.
Plus rarement on déploie, moins on a confiance dans sa procédure de déploiement et la peur du déploiement commence à s'installer dans l'équipe.
Plus rarement on déploie, moins les développeurs attachent de l'importance à la procédure de déploiement, car celle-ci prend moins de place dans leur travail et qu'ils ont normalement bien assez de problèmes pour occuper leur temps.
Plus rarement on déploie, plus la procédure de déploiement diverge de l'application, et plus les effets sont imprévisibles au prochain déploiement... ce qui accentue la peur du déploiement.
Plus rarement on déploie, plus la procédure de déploiement introduit une incertitude difficile à évaluer sur la livraison. On croit avoir fini, à entendre les développeurs, mais en réalité il reste beaucoup de travail à faire parcequ'on a privilégié les "features" au déploiement sans tenir compte du fait que non déployée une "feature" est un investissement sans gain.
On peut étoffer cette liste à l'envi. Cependant même si on déploie tout tout de suite, on a à sa disposition plein de techniques qui permettent de faire cela sans pour autant introduire des incompatibilités ou dégrader le ressenti et le travail des utilisateurs.
Pour des arguments d'une toute autre nature, les auteurs du petit livre "Accelerate" expliquent en se basant sur leur large observation empirique que les entreprises technologiques qui ont les meilleures résultats sont celles qui optimisent quatre métriques particulières ("4 key metrics") et que l'adoption de la livraison continue est un changement organisationnel qui par essence optimise ces quatre métriques.
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 6.
Même si il y a apparemment de bonnes raisons de ne pas forcément vouloir déployer à chaque push, l'argument les plus important pour cette pratique, à mes yeux, suit le plan suivant:
Il faut toujours être en capacité de déployer car on peut avoir besoin de corriger un problème grave.
Plus rarement on déploie, moins on a confiance dans sa procédure de déploiement et la peur du déploiement commence à s'installer dans l'équipe.
Plus rarement on déploie, moins les développeurs attachent de l'importance à la procédure de déploiement, car celle-ci prend moins de place dans leur travail et qu'ils ont normalement bien assez de problèmes pour occuper leur temps.
Plus rarement on déploie, plus la procédure de déploiement diverge de l'application, et plus les effets sont imprévisibles au prochain déploiement... ce qui accentue la peur du déploiement.
Plus rarement on déploie, plus la procédure de déploiement introduit une incertitude difficile à évaluer sur la livraison. On croit avoir fini, à entendre les développeurs, mais en réalité il reste beaucoup de travail à faire parcequ'on a privilégié les "features" au déploiement sans tenir compte du fait que non déployée une "feature" est un investissement sans gain.
On peut étoffer cette liste à l'envi. Cependant même si on déploie tout tout de suite, on a à sa disposition plein de techniques qui permettent de faire cela sans pour autant introduire des incompatibilités ou dégrader le ressenti et le travail des utilisateurs.
Pour des arguments d'une toute autre nature, les auteurs du petit livre "Accelerate" expliquent en se basant sur leur large observation empirique que les entreprises technologiques qui ont les meilleures résultats sont celles qui optimisent quatre métriques particulières ("4 key metrics") et que l'adoption de la livraison continue est un changement organisationnel qui par essence optimise ces quatre métriques.