DevOps – Le ROI est mort, vive le ROI !

DevOps – Le ROI est mort, vive le ROI !

Quand on intègre le service informatique d’une grosse et vénérable compagnie industrielle, on vous fait rapidement comprendre que le cœur de métier, la valeur de l’entreprise réside dans la manufacture et la vente de son produit phare, pas dans son SI. Fair enough. Cependant, cet état de fait devient problématique lorsque cette même société décide d’opérer une transformation digitale de son activité. Car une transformation digitale coûte cher, en temps comme en ressources. Elle peut s’avérer risquée à de nombreux égards (mauvaise identification des besoins, mauvaise qualification des solutions, changements hasardeux et précipités, manque de connaissances et compétences etc) et, mal maîtrisée ou prise trop tard, peut même faire pâtir le produit final (voir le cas d’école Jaeger, qui illustre pourquoi cette transformation est nécessaire, mais on peut également citer Kodak, Nokia et même dans une certaine mesure Boeing et Microsoft). Jaeger, un style aussi désuet que leur stratégie digitale Dès lors, il devient compliqué de cacher son dédain (spirituel mais surtout financier) envers l’IT en invoquant la priorité au produit final. Car si, dans les industries traditionnelles, l’informatique n’intervient pas (ou peu) dans la réalisation de ce dernier, elle en est en revanche le premier support, du bureau d’étude à la livraison. On ne peut donc plus décemment renier aux services informatiques leurs besoins grandissant d’investissement et décorréler la valeur du service qu’ils apportent de celle du produit qu’ils servent. Tout est lié. « Oui mais… Je tiens à mon argent. Je veux le faire prospérer. J’ai l’habitude de calculer le coût de mon produit. Après tout, il ne s’agit que de la somme de ses matières premières, des...
DevOps Day #2 à Hambourg

DevOps Day #2 à Hambourg

De Toulouse à Hambourg Si vous avez lu notre dernier article de décembre traitant de l’expertise DevOps de Quadran, vous ne serez pas surpris d’apprendre que nous organisons également des événements autour de ce sujet. Le dernier en date est le DevOps Day, deuxième édition qui eut lieu le 11 janvier 2018 à Hambourg. Cet événement est la continuité logique du premier DevOps Day, organisé à Toulouse en juillet, qui avait réuni une cinquantaine de participants. En résumé 130 invités, 89 participants, 15 animateurs, 11 corners, 2 serious games , 1 table ronde et de la bonne humeur ! Des participants très impliqués et curieux faces à des animateurs de corners passionnés dont les sujets variés ont été présentés de façon ludique, congratulation toute particulière à Julien Alves pour son implication et son imagination ! Les différents sujets ont permis de bien évaluer les prérequis et objectifs d’une transformation DevOps, que se soit au niveau des outils (Ansible, GitHub, Jira, Docker, Sonarqube, Selenium, Splunk, Slack..), du besoin de redéfinir certains rôles et responsabilités, de l’importance d’une gestion de configuration adaptée et robuste, de l’automatisation des tests ou bien de l’accompagnement nécessaire pour envisager à court terme une intégration continue plus efficace mais en s’assurant de maintenir toujours le même niveau de qualité. Et maintenant ? Quant à la suite de nos aventures DevOps, Quadran commence déjà à réfléchir à la préparation de la troisième édition des DevOps Days, qui devrait avoir lieu à Madrid (hasta pronto Madrid!). L’objectif de ces DevOps Days étant de partager, d’échanger et d’informer sur les prérequis et objectifs de cette nouvelle façon de travailler (ou...
L’expertise DevOps de Quadran au service d’Airbus

L’expertise DevOps de Quadran au service d’Airbus

En plus de son activité d’éditeur de logiciel, Quadran accompagne des grands comptes comme Airbus dans leur transformation digitale. Début 2017, nous intégrons le programme de transformation qui a pour but dans un premier temps de redonner aux équipes de développement la main sur les déploiements applicatifs. Déploiements qui auparavant étaient de la responsabilité des équipes d’exploitation, les équipes projets ne pouvant pas livrer. Cette transition s’inscrit comme point de départ d’une démarche globale d’Airbus qui souhaite orienter son département ICT vers du DevOps. Lors de cette première étape, nous avons supervisé le transfert d’activité d’une dizaine de bundle, depuis la phase de sensibilisation, les sessions de training, l’intégration des nouvelles activités jusqu’aux impacts contractuels liés aux périmètres de responsabilité de chaque acteur. Cette première transition – aujourd’hui terminée – donne aux équipes de développement une plus grande flexibilité et maîtrise de leurs déploiements et permet de s’orienter vers le DevOps dont l’un des principes et le contrôle end-to-end du produit (Plan/Code/Build/Test/Release/Operate), notion qui est aujourd’hui centrale chez Airbus. C’est dans ce contexte de transformation DevOps que Quadran intervient et plus précisément sur les aspects « Tooling / Automation ». Embarqué au sein de l’équipe transformation, la mission de Quadran est de communiquer sur les outils mis en place puis, dans un second temps récolter les besoins des différentes équipes pour leur proposer l’accompagnement adéquat en terme d’expertise, tout en étant au plus près de leur contexte. Aujourd’hui plusieurs projets pilotes sont en cours d’accompagnement dans la mise en place de leurs outils de projets agiles et déploiements automatisés avec l’objectif final de pouvoir déployer en continue sur des...
Transformation DevOps et Performance Web

Transformation DevOps et Performance Web

D’ici 2018, le Gartner prévoit qu’une entreprise sur deux aura mis en place une solution de Release Automation pour faciliter sa transformation DevOps. Le concept DevOps Le concept DevOps consiste à rapprocher les équipes de DEVeloppement et OPérationnelleS, afin de faciliter et d’automatiser les mises à jour logicielles de plus en plus fréquentes sur les environnements de production. L’objectif principal est de réduire significativement les interminables cycles de livraison dans les organisations traditionnelles en silos, et l’objectif sous-jacent mais pas moindre est de maintenir le même niveau de qualité des livraisons. Le cycle DevOps : L’intégration continue Dans une démarche classique d’intégration continue, les équipes projets développent les solutions, elles passent ensuite la main à leurs confrères de l’exploitation en fin de cycle pour prendre en charge le déploiement en tenant compte des contraintes de production. Ces métiers sont bien différents et dans la pratique on note souvent des intervenants avec des profils très distincts. Automatiser le déploiement des applications, c’est d’abord définir des processus dépendant de l’entreprise voire des organisations internes. Il faut ensuite s’assurer qu’opérationnellement tous les acteurs de l’intégration continue suivront bien les règles de base de la gestion de configuration : Définir les packages à livrer, Stocker les livraisons avec la documentation associée, Tester les livraisons sur les différents environnements (intégration, validation, production), Fournir des versions gérées en configuration pour les équipes de tests (techniques ou fonctionnelles). Revenons maintenant à notre solution de Release Automation, en conclusion elle devra permettre d’automatiser ces processus de livraisons qui jusque-là étaient supportées uniquement par les équipes OPS. La Performance Web Dans notre univers de l’analyse des performances applicatives, cela...