Emmanuel Favreau, Responsable du pôle BI chez Axones
Le goulot d’étranglement du processus ? La mise en production ! Le nombre toujours grandissant des applications livrées se voyant ralenti par les exploitants… Les Directions études s’opposent aux Directions Exploitations,
leur reprochant de ne pas être assez réactives. Quant à ces dernières, elles reprochent aux Etudes de ne pas tenir compte de leurs contraintes et de ne pas comprendre que le Système d’Information est un environnement contraint,
dans lequel toutes les briques sont interdépendantes les unes des autres, et dont la stabilité et la sécurité doivent être garanties.
Des exemples concrets et leurs travers
Prenons deux exemples, représentatifs de ce qui se passe actuellement dans les entreprises :
Ÿ Un développeur, ayant développé un contact de proximité avec une personne de la production, « bypasse » le processus mis en place, et grâce à cette complicité, délivre plus vite son projet, au bénéfice de l’utilisateur.
Ÿ Autre exemple, un environnement de développement qui se transforme en environnement de production géré uniquement par la MOE, sans que la production n’en ait connaissance. L’utilisateur bénéficiera là aussi
d’un temps de réactivité plus rapide.
Dans ces deux exemples précédents, la rapidité de livraison est favorisée. Nous serions donc enclins à dire que les utilisateurs seront satisfaits, et que par conséquent le modèle serait de laisser les services de développement
gérer les environnements … Jusqu’au moment où l’environnement de développement tombera et que la production ne pourra intervenir que plusieurs heures après, en restaurant un ancien backup puisque le serveur
n’aura pas été étiqueté comme critique ! Conséquence : une perte de temps, d’efficacité, de réactivité, de savoir-faire…
Rapprocher développement et production
Le climat de défiance entre développement et production est dû à la différence sémantique de deux métiers aux intérêts divergents. Les développeurs, s’appuyant sur les méthodes agiles, cherchent à répondre rapidement
aux besoins et demandes d’évolutions du métier. Ce qui traduit par des livraisons et des demandes de mise en production beaucoup plus rapprochées, augmentant par contre le risque d’instabilité.
De l’autre côté, l’équipe d’exploitation doit s’assurer que le système d’information de l’entreprise est un environnement stable, sécurisé et pérenne dans le temps selon les recommandations ITIL, le tout dans un contexte
de réduction des coûts et de mutualisation.
Né de cette opposition, le mouvement DevOps vise à rapprocher les deux équipes et à aligner leurs objectifs sur les besoins de l’entreprise. Le terme vient de la contraction de deux termes anglais : « Development »
qui désigne les équipes de développement et « Operations » qui correspond à l’équipe en charge de l’exploitation et de la production des serveurs. Mouvement récent, DevOps commence à émerger et se trouve actuellement
dans la liste des « dossiers chauds » des DSI. Mais pour qu’il porte ses fruits, il doit impérativement s’appuyer sur une nouvelle forme d’organisation des équipes favorisant la communication, des processus partagés et des outils.
Une meilleure communication
Historiquement, les équipes de développement et d’exploitation sont séparées, tant d’un point de vue tant géographique que des objectifs. Le premier chantier sera donc de rapprocher ces équipes pour permettre
une meilleure compréhension des contraintes de chacun, en organisant par exemple des ateliers permettant de faire travailler ces équipes ensemble. Autre point important : définir des objectifs communs, car c’est
en partageant un même but et ensuite la réussite d’un projet, que les collaborateurs pourront se rapprocher et se comprendre.
Des processus partagés
La mise en place de processus adaptés et surtout efficaces car suivis par tous, ne peut se faire qu’après avoir identifié et intégré l’ensemble des contraintes. Le curseur devra être mis de manière à respecter des temps et fréquences
de livraison attendus par l’entreprise, tout en garantissant la qualité et la fiabilité des systèmes. C’est au niveau de l’équilibre de cette équation que résidera la capacité du « Dev » à adhérer au « Ops » !
Un outillage adéquat
Des processus non outillés ne pourront clairement pas répondre aux exigences de communication, de qualité, de standardisation et de fluidité. Mais cela nécessite un outillage adéquat et une formation des deux équipes.
L’outillage devra permettre d’industrialiser le cycle de vie d’une application l’ALM (Application Lifecycle Managment) et en particulier les outils favorisant la communication entre les deux parties : gestion du versionning et
industrialisation des transports de composants, pour permettre de faire du déploiement continu (Continuous Deployment). Les livrables sont ainsi déployés automatiquement dans les différents environnements en suivant
un processus de validation. Les géants du web Google, Facebook, Amazon le font déjà plusieurs fois par jour sans que leurs utilisateurs ne s’en rendent compte !
Cette démarche, même si elle est ambitieuse, doit s’aborder itérativement, pour gagner ensuite l’ensemble du SI.
Des bénéfices indiscutables
Au-delà d’un terme marketing dans l’ère du temps, DevOps apporte de réels bénéfices à l’entreprise. Une récente étude menée auprès de plus de 9 200 professionnels (Puppet Labs - 2014) met indiscutablement
en lumière les gains de performance enregistrés par les entreprises l’ayant adopté. Même si cela va prendre un peu de temps, DevOps va petit à petit s’imposer dans nos entreprises comme les méthodes Agiles ont réussi à le faire.
Et ce pour le bien de tous, des équipes de production comme de développement, des utilisateurs comme des dirigeants.
leur reprochant de ne pas être assez réactives. Quant à ces dernières, elles reprochent aux Etudes de ne pas tenir compte de leurs contraintes et de ne pas comprendre que le Système d’Information est un environnement contraint,
dans lequel toutes les briques sont interdépendantes les unes des autres, et dont la stabilité et la sécurité doivent être garanties.
Des exemples concrets et leurs travers
Prenons deux exemples, représentatifs de ce qui se passe actuellement dans les entreprises :
Ÿ Un développeur, ayant développé un contact de proximité avec une personne de la production, « bypasse » le processus mis en place, et grâce à cette complicité, délivre plus vite son projet, au bénéfice de l’utilisateur.
Ÿ Autre exemple, un environnement de développement qui se transforme en environnement de production géré uniquement par la MOE, sans que la production n’en ait connaissance. L’utilisateur bénéficiera là aussi
d’un temps de réactivité plus rapide.
Dans ces deux exemples précédents, la rapidité de livraison est favorisée. Nous serions donc enclins à dire que les utilisateurs seront satisfaits, et que par conséquent le modèle serait de laisser les services de développement
gérer les environnements … Jusqu’au moment où l’environnement de développement tombera et que la production ne pourra intervenir que plusieurs heures après, en restaurant un ancien backup puisque le serveur
n’aura pas été étiqueté comme critique ! Conséquence : une perte de temps, d’efficacité, de réactivité, de savoir-faire…
Rapprocher développement et production
Le climat de défiance entre développement et production est dû à la différence sémantique de deux métiers aux intérêts divergents. Les développeurs, s’appuyant sur les méthodes agiles, cherchent à répondre rapidement
aux besoins et demandes d’évolutions du métier. Ce qui traduit par des livraisons et des demandes de mise en production beaucoup plus rapprochées, augmentant par contre le risque d’instabilité.
De l’autre côté, l’équipe d’exploitation doit s’assurer que le système d’information de l’entreprise est un environnement stable, sécurisé et pérenne dans le temps selon les recommandations ITIL, le tout dans un contexte
de réduction des coûts et de mutualisation.
Né de cette opposition, le mouvement DevOps vise à rapprocher les deux équipes et à aligner leurs objectifs sur les besoins de l’entreprise. Le terme vient de la contraction de deux termes anglais : « Development »
qui désigne les équipes de développement et « Operations » qui correspond à l’équipe en charge de l’exploitation et de la production des serveurs. Mouvement récent, DevOps commence à émerger et se trouve actuellement
dans la liste des « dossiers chauds » des DSI. Mais pour qu’il porte ses fruits, il doit impérativement s’appuyer sur une nouvelle forme d’organisation des équipes favorisant la communication, des processus partagés et des outils.
Une meilleure communication
Historiquement, les équipes de développement et d’exploitation sont séparées, tant d’un point de vue tant géographique que des objectifs. Le premier chantier sera donc de rapprocher ces équipes pour permettre
une meilleure compréhension des contraintes de chacun, en organisant par exemple des ateliers permettant de faire travailler ces équipes ensemble. Autre point important : définir des objectifs communs, car c’est
en partageant un même but et ensuite la réussite d’un projet, que les collaborateurs pourront se rapprocher et se comprendre.
Des processus partagés
La mise en place de processus adaptés et surtout efficaces car suivis par tous, ne peut se faire qu’après avoir identifié et intégré l’ensemble des contraintes. Le curseur devra être mis de manière à respecter des temps et fréquences
de livraison attendus par l’entreprise, tout en garantissant la qualité et la fiabilité des systèmes. C’est au niveau de l’équilibre de cette équation que résidera la capacité du « Dev » à adhérer au « Ops » !
Un outillage adéquat
Des processus non outillés ne pourront clairement pas répondre aux exigences de communication, de qualité, de standardisation et de fluidité. Mais cela nécessite un outillage adéquat et une formation des deux équipes.
L’outillage devra permettre d’industrialiser le cycle de vie d’une application l’ALM (Application Lifecycle Managment) et en particulier les outils favorisant la communication entre les deux parties : gestion du versionning et
industrialisation des transports de composants, pour permettre de faire du déploiement continu (Continuous Deployment). Les livrables sont ainsi déployés automatiquement dans les différents environnements en suivant
un processus de validation. Les géants du web Google, Facebook, Amazon le font déjà plusieurs fois par jour sans que leurs utilisateurs ne s’en rendent compte !
Cette démarche, même si elle est ambitieuse, doit s’aborder itérativement, pour gagner ensuite l’ensemble du SI.
Des bénéfices indiscutables
Au-delà d’un terme marketing dans l’ère du temps, DevOps apporte de réels bénéfices à l’entreprise. Une récente étude menée auprès de plus de 9 200 professionnels (Puppet Labs - 2014) met indiscutablement
en lumière les gains de performance enregistrés par les entreprises l’ayant adopté. Même si cela va prendre un peu de temps, DevOps va petit à petit s’imposer dans nos entreprises comme les méthodes Agiles ont réussi à le faire.
Et ce pour le bien de tous, des équipes de production comme de développement, des utilisateurs comme des dirigeants.
