Alain: Donc Alain Delafosse. Je travaille chez Kelkoo depuis 8 ans, mon rôle c'est architecte, au sens large, et j'essaye de travailler plutôt sur les aspects à la fois infrastructure et architecture logicielle. Et à ce titre là, j'ai très vite été concerné par les aspects autour de DevOps...
Eric: Et donc Eric Mattern, je suis Manager Open Source chez Objet Direct, je suis en charge du lancement des nouvelles offres. Je dirais que c'est une société de service en informatique spécialisée dans les architectures Java, et dans les méthodologies Agiles.
Alain: Côté Kelkoo on s'est vraiment intéressé au monde DevOps quand on a été rachetés, on a vécu une petite période sous l'aile protectrice de Yahoo. On a découvert que finalement la manière dont on déployait nos applications pouvait être automatisée, Yahoo avait tout un ensemble d'outillages et de pratiques mises en place. Quand Yahoo nous a revendu, on s'est retrouvés dans une situation où on ne pouvait plus utiliser l'outillage de Yahoo, et donc on s'est dit qu'il y a quand même un certain nombre de pratiques ou de choses qui sont vraiment importantes, qui apportent de la valeur dans notre organisation, et on est partis finalement à reconstruire ou à refaire tout cet ensemble d'outillage et de principes et à les mettre en perspective chez nous.
Eric: Côté Objet Direct on suis forcément de près l'évolution du mouvement DevOps, étant spécialistes de la production logicielle et de la performance de la production logicielle, grâce à l'agilité on améliore sans cesse les techniques, les méthodes de développement. Donc pour nous DevOps c'est une continuité à ce qu'on a pu mettre en pratique depuis des années sur la partie production logicielle, effectivement on veux améliorer le Time-to-Market, on veux améliorer la performance logicielle, et pour nous DevOps est un moyen d'y arriver.
4. InfoQ: Quel est le principal impact des principes DevOps sur l'organisation d'un projet ?
Alain: Déjà c'est qu'auparavant dans le cycle de développement il y avait vraiment une étape où on concevait et on testait le logiciel, et puis seulement on allais voir la prod pour leur dire "bon au fait les gars, pour demain il faut que ça marche". La grosse tendance maintenant c'est qu'on commence à intégrer, enfin c'est pas qu'on commence, c'est qu'on intègre de façon plus ou moins profonde (ce sont différents modèles) des gars des Ops dans des Scrum Agiles, par exemple, typiquement qui viennent pour certains aux stand-ups, au minimum au sprint planning, et qui commencent à s'intéresser dès le début de la conception ou de la création des critères d'acceptance, de ce genre d'aspects, à "comment ça va fonctionner en prod?". Donc c'est une relation déjà bien plus forte. L'autre impact de cette relation plus forte c'est par exemple si la personne des Ops viens au stand-up fréquemment, et bien elle peut faire un retour sur ce qu'il se passe en prod, elle peut dire "vous êtes bien gentils les gars avec votre dernière release, mais là ça fait quand même 3 semaines que je me bat toutes les nuits à essayer de stabiliser le bousin, si vous pouviez corriger ce bug là ça rendrait quand même ma vie plus facile". Et là où avant il y avait un flot documentaire, des bugfixes (finalement à cause des deux organisation on cherchait à documenter un maximum les flux d'information entre les deux organisations) et bien là il y a un contact direct beaucoup plus fort.
Eric: Oui, oui nous l'agilité on la pratique depuis des années, ça permet réellement de rapprocher les équipes qui n'ont pas forcément la même culture, les mêmes habitudes et les mêmes objectifs. Donc là on parle plutôt des métiers, qui vont devoir travailler, dialoguer, partager les mêmes objectifs avec les équipes de développement. Donc on retrouve les mêmes similitudes entre ces équipes de développement qui devront également travailler avec les équipes de production.
Alain: Et bien nous on a identifié par exemple dans la partie un peu Innovation Games que souvent jouer ou prendre un peu de recul c'est un moyen comme dans toute transition d'essayer de prendre un peu de recul et de rigoler de ses propres pratiques. Il y a de très bons jeux, style "artiste et spécifieur" par exemple. Tout le monde a connu l'époque où l'on faisait de gros dossiers de mise en production qu'on donnait aux opérations, etc... Une fois qu'on a joué à ce jeu là (il y en a un qui ne peux pas parler, et l'autre qui peux juste dessiner), c'est vraiment une mise en perspective que la communication par écrit elle a vraiment ses limites et que la communication directe, orale, parfois elle apporte bien plus de valeur, même à travers Skype si on est à distance, et que par exemple c'est à travers ce genre de jeux, de petites pratiques ou autres, en prenant un peu de recul, qu'on va changer étape après étape la culture. C'est une des pistes.
7. InfoQ: Essayer donc de gamifier un peu le processus...
Eric: Oui, il y a effectivement la gamification au départ, ensuite il y a l'usage des métriques. Donc c'est partager en gros la même vision, les mêmes métriques de performances. C'est à dire que ces métriques vont permettre de voir une progression dans l'évolution DevOps et de concentrer l'ensemble des acteurs autour des mêmes pôles d'attention.
8. InfoQ: Donc il est important de tout bien mesurer, d'avoir cette perspective tôt dans le process.
Alain: Oui
Alain: Non pas tout à fait, parce que peut-être même à l'opposé d'une organisation IT classique la production elle est vraiment vitale dans notre organisation. Si nos outils web ne marchent pas, c'est nos revenus qui ne rentrent pas. C'est même pas une usine où finalement la production est bloquée, on peut peut-être gérer avec les stocks, là c'est une relation très directe et immédiate entre les revenus et la bonne qualité du site. Donc ça veux dire que tout changement que l'on fait en production, et bien finalement il peut avoir un impact très direct sur le revenu, et on peut le mesurer assez simplement d'ailleurs. Donc ça veux dire que la résistance au changement, à la fois dans les pratiques et autres, et bien elle est importante. Et puis c'est une plate-forme également complexe, peut-être plus complexe, où on développe énormément notre propre logiciel, donc l'intégration, le déploiement, la monté en charge, ça fait que tout ces aspects là rendent les acteurs plus prudents, et la résistance au changement est quand même présente.