# data[].attributes.headline
le lean applique a un centre de services

# data[].attributes.subject
le lean applique a un centre de services

# data[].attributes.body
https://www.journaldunet.com/solutions/expert/45488/le-lean-applique-a-un-centre-de-services.shtml

# data[].attributes.body
Devops

# data[].attributes.body
Ce document permet de comprendre le DEVOPS

# data[].attributes.attachment_link.description
Ce parcours vous permet de d'acquérir les notions et les outils indispensables pour comprendre le rôle de Product Owner...

# data[].attributes.attachment_link.title
devops REX 2017 - Oser ralentir pour aller + vite, histoire d’une révolution culturelle non violente

# data[].attributes.attachment_link.provider_name
Blog Xebia - Expertise Technologique & Méthodes Agiles

# data[].attributes.attachment_link.readable_text
Il y a 1 année · 9 minutes · DevOps

Dans cet article d'introduction à DevOps je vous propose de revenir aux bases du mouvement DevOps : ses origines, motivations et principaux enjeux. J'aborderai les pratiques C.A.L.M.S. ( Culture Automation Lean Measurement S haring) bien connues par tous les "pratiquants" de ce mouvement.

Cet article est destiné tout d'abord à tous ceux qui veulent découvrir les pratiques DevOps et comprendre pourquoi DevOps est devenu quasiment indispensable pour tout nouveau projet agile. Les gourous de DevOps pourront également trouver quelques informations intéressantes pour rafraîchir leur mémoire.

Introduction

Définition

Il n'existe pas de définition de DevOps unique et acceptée par tout le monde. Par conséquent, il y a des dizaines de définitions différentes visant à expliquer ce mouvement.

Voici la définition fournie par Wikipedia :

" Le DevOps est un mouvement visant à l'alignement de l'ensemble des équipes du système d'information sur un objectif commun, à commencer par les équipes de Dev chargées de faire évoluer le système d'information et les Ops responsables des infrastructures. " ( Wikipedia)

Cette définition, certes très brève, donne un bon aperçu permettant de comprendre de quoi il s'agit : une collaboration étroite entre les équipes des Devs et des Ops. Voici une autre définition que je trouve intéressante :

" DevOps est la pratique où les ingénieurs de développement (Dev) et d'exploitation (Ops) participent ensemble à l'intégralité du cycle de vie de services : de la conception au support de production en passant par le développement. "

Origines

L'histoire de DevOps commence en Belgique où Patrick Debois, ingénieur de développement, exerce depuis 15 ans les différents rôles suivants au sein de grandes entreprises : développeur, ingénieur réseaux, administrateur système et chef de projet. En 2007, il travaille en tant que testeur pour un grand projet de migration de datacenter. Il est amené à collaborer à la fois avec les équipes de développement et les équipes opérationnelles. Patrick est particulièrement frustré par le contraste entre les façons dont les Devs et les Ops travaillent et le conflit perpétuel entre ces deux mondes. Il est persuadé qu'il existe un moyen d'améliorer cette collaboration et de mieux s'aligner.

En 2009 Patrick assiste à la présentation " 10+ Deploys per Day: Dev and Ops Cooperation at Flickr " donnée par deux employés de Flickr - John Allspaw et Paul Hammond, lors de la conférence O'Reilly. Patrick est tellement inspiré par cette présentation qu'il décide d'organiser sa propre conférence appelée Devopsdays à Gand en Belgique en octobre 2009.

Depuis 2010 le Twitter hashtag #DevOps est la source essentielle d'information liée au mouvement.

Les Rôles

Avant de commencer notre "deep-dive" dans le monde de DevOps, rappelons-nous le rôle de chaque participant pour lever toute ambiguïté possible :

Rôle des Devs : Quand on parle des Devs, on parle de toute personne impliquée dans la fabrication du logiciel avant qu'il n'atteigne la production : les développeurs, les gestionnaires de produits, les testeurs, les Product Owners et les QAs.

Rôle opérationnel : Il s'agit de tout le monde impliqué dans l'exploitation et la maintenance de la production: les ingénieurs systèmes, les DBAs, les ingénieurs réseaux, le personnel de sécurité, etc.

Les Développeurs (Dev) sont chargés de produire de l'innovation et délivrer les nouvelles fonctionnalités aux utilisateurs dès que possible. Les Ingénieurs d'opérations (Ops) sont chargés de s'assurer que les utilisateurs ont accès à un système stable, rapide et réactif :

Les Dev recherchent des changements ;

Les Ops recherchent la stabilité organisationnelle.

Bien que le but ultime de Dev et Ops soit de rendre l'utilisateur satisfait (et potentiellement heureux, client payant) des systèmes qu'ils fournissent, leurs visions sur la façon de le faire restent diamétralement opposées.

Dev vs Ops

Dev vs Ops

Quand les Dev et Ops vivaient dans leurs mondes isolés, cette opposition ne posait pas de problème. Les deux travaillaient " on a schedule " en collaborant seulement pendant les rares phases des releases. Les Devs savaient qu'ils devaient délivrer toutes les fonctionnalités désirées pour le jour " J ", sinon il leur fallait attendre le prochain créneau. Et les Ops avaient suffisamment de temps pour tester les nouvelles fonctionnalités avant de les envoyer en production. Ils pouvaient ensuite prendre des jours, voire des nuits, pour déployer ces releases aux utilisateurs.

Maintenant les choses ont changé, radicalement !
Les contraintes business ont évolué d'une telle manière que les utilisateurs veulent les nouvelles fonctionnalités très rapidement. Avec l'intégration et la livraison continue les développeurs font de nouvelles releases chaque jour. Il n'y a plus de jour " J " pour délivrer le produit comme auparavant.

Les Ops ne peuvent plus prendre des jours pour déployer des fonctionnalités une fois qu'elles ont été testées, néanmoins ils doivent maintenir la stabilité.

Dev AND Ops

DevOps et ses pratiques visent à mettre fin à cette bataille entre Dév et Ops - pour parvenir à l'équilibre entre l'innovation et la stabilité. Dev et Ops doivent comprendre les bénéfices des paradigmes DevOps. Ils ont besoin de changer juste assez pour commencer à travailler ensemble et à trouver le bon alignement entre Dev et Ops dont leur organisation a besoin, et de s'améliorer à partir de là.

Ce que DevOps n'est pas

Nous avons beaucoup d'outils pour le déploiement, le monitoring, etc., mais DevOps ne se limite pas à leur utilisation. Il s'agit des changements organisationnels profonds qui peuvent être appuyés par ces outils.

Le cycle de vie d'un logiciel

Le cycle de vie traditionnel

Le besoin en DevOps est né de la popularité croissante du développement en mode agile qui conduit à un nombre accru de versions. L'un des objectifs de DevOps est d'établir un environnement qui favorise les release fiables, délivrées plus fréquemment et plus rapidement. Essentiellement, les méthodes agiles ont été utilisées uniquement pour la partie de développement de logiciel. Les Ops n'étaient pas habituellement inclus dans ce processus.

Par la suite, le code a été donné aux Ops - ou plutôt jeté par-dessus le Mur de la Confusion.

Cycle de vie DevOps

Alors vous pouvez demander " en quoi le cycle de vie de DevOps est-il différent ? "

Il peut être résumé avec l'acronyme C.A.L.M.S. :

Culture

DevOps est plus qu'un simple outil ou un changement de processus. Il exige le changement de la culture organisationnelle. Ce changement culturel est particulièrement difficile à cause des rôles conflictuels des départements. Les Ops recherchent la stabilité organisationnelle ; les développeurs cherchent les changements ; et les testeurs cherchent à réduire les risques. Faire travailler ces groupes de manière cohérente est un défi crucial de l'adoption de DevOps dans l'entreprise.

Une grande source d'inspiration pour DevOps est l'Agile, et l'un des points-clés agiles dit :

" Les individus et les interactions plutôt que les processus et les outils "

Automation

Les machines sont vraiment bonnes à faire la même tâche encore et encore.
Automatiser autant que possible ! C'est quelque chose que les Ops ont fait pour rendre leur travail plus facile, mais qui n'a pas été reconnu comme une fonction vitale de l'organisation. Aujourd'hui l'organisation peut avoir des milliers de serveurs. À cette échelle cela n'est plus gérable à la main. Nous avons besoin d'automatisation pour faire le travail.

Lean

" Lean " est également la source d'inspiration pour la culture DevOps. Lean est centré sur la rationalisation des opérations, en réduisant les déchets et maximisant la valeur du client.
Lean dit qu'il est indispensable d'améliorer l'ensemble du flux et non seulement certains points dans le pipeline de production.

Les équipes Devs et les équipes Ops doivent trouver des moyens pour réduire les déchets et rationaliser les processus en entier.

Measurement

Si vous voulez améliorer quelque chose, vous devez être capable de le mesurer. Supposons qu'une nouvelle version du logiciel devrait rendre l'application plus rapide. Comment savez-vous qu'elle est plus rapide ? Le seul moyen est de le mesurer.

Dans les organisations informatiques traditionnelles, la surveillance des infrastructures était la responsabilité des Ops. Cette approche est quand-même réductrice, car le service ne se limite pas à un ensemble de serveurs. Avec la participation de l'équipe de développement nous pouvons fortement améliorer le monitoring. Les développeurs peuvent s'assurer que l'application exporte des données utiles.

Sharing

Il est très important d'aligner toutes les parties prenantes sur les mêmes objectifs - les pratiques et les flux. Tous les intervenants devraient participer et travailler ensemble pour formuler les objectifs finaux, car cela crée le sens de la propriété. Les gens sont prêts à travailler ensemble quand leurs pensées et leurs opinions sont entendues.

Il est important d'éliminer les goulets d'étranglement à l'intérieur des départements ou entre eux ;

Il est également important de partager les avantages entre les équipes.

Conclusion

L'automatisation des tests unitaires et des tests d'integration est l'Intégration Continue ! Cela aide au développement itératif et assure que les changements des nouvelles fonctionnalités ne cassent pas d'autres fonctionnalités. L'automatisation de tout le processus jusqu'à la "release" est couverte par la Livraison Continue. Pour s'assurer que tout fonctionne bien et améliorer l'ensemble des processus au fil du temps, il est nécessaire de tout Mesurer (Monitoring). Pour que cette mesure soit possible il est nécessaire d'avoir une bonne Communication dans la Culture du Partage et de la Collaboration, quand toute l'équipe est impliquée.
Avoir de l'automatisation c'est bien, mais ce n'est qu'en la combinant avec la culture de la communication et la collaboration entre les équipes qu'on obtient l'Approche DevOps pour le cycle de vie du logiciel.

Dans notre prochaine article nous allons continuer le deep dive dans le monde DevOps avec l' infrastructure-as-code.

# data[].attributes.attachment_link.title
Introduction à DevOps - Blog Xebia - Expertise Technologique & Méthodes Agiles

# data[].attributes.attachment_link.description
Dans cet article d'introduction à DevOps je vous propose de revenir aux bases du mouvement DevOps : ses origines, motivations et principaux enjeux. J'aborderai les pratiques C.A.L.M.S. (Culture Automation Lean Measurement Sharing) bien connues par tous les "pratiquants" de ce mouvement. Cet article est destiné tout d'abord à tous ceux qui veulent découvrir les pratiques...

# data[].attributes.attachment_link.readable_text
Devops se définit comme un mouvement visant à aligner le système d'information sur les besoins de l'entreprise. DevOps est la concaténation des trois premières lettres du mot anglais Development (développement) et de l'abréviation usuelle (Ops) du mot anglais operations (exploitation), deux fonctions de la gestion des systèmes informatiques qui ont souvent des objectifs contradictoires (Source : Wikipedia). Le blog IT Revolution Press propose une histoire de cette tendance très récente.

# data[].attributes.attachment_link.description
Devops se définit comme un mouvement visant à aligner le système d'information sur les besoins de l'entreprise. DevOps est la concaténation des trois premières lettres du mot anglais Development (développement) et de l'abréviation usuelle (Ops) du mot anglais operations (exploitation), deux fonctions de la gestion

# data[].attributes.attachment_link.readable_text
Beaucoup d'entreprises sont en train d'effectuer des virages numériques. Cette révolution digitale implique souvent une réorganisation de la DSI " cheville ouvrière " ou " consultant technique " de l'accompagnement au changement de l'entreprise.

Le terme DevOps est souvent lâché comme solution miracle. Nous vous proposons une petit historique de ce presque " buzzword " qui cache une vraie réalité opérationnelle.

DevOps : qu'est ce que c'est ?

Le DevOps se définit comme un mouvement visant à aligner le système d'information sur les besoins de l'entreprise. L'idée est simple : travailler ensemble pour gagner en productivité et " réussir une dizaine de déploiement par jour ". A noter que dans le process actuel et habituel (non DevOps), un projet standard peut réaliser un seul déploiement par semaine si tout se passe bien, et un tout les 6 mois quand ce n'est pas le cas...)

Ce mouvement se veut comme une réponse à la prise de conscience du fossé entre les développeurs et les administrateurs systèmes et réseaux (Opérationnels) et a pour but de réduire les conflits et les problèmes d'inefficacité en supprimant ce " mur de la confusion " comme aiment le dire Andrew Shafer et Lee Thompson.

Damon Edwards, s'il te plaît, raconte nous une histoire ...

Afin que vous abordiez au mieux ce concept et connaissiez toute l'histoire, voici la vidéo la racontant : " the short history of DevOps " :

En résumé :

2007 : Lors d'une migration de données pour le gouvernement Belge, Patrick Debois - administrateur système et consultant - subit et se frustre des relations entre les développeurs et les administrateurs systèmes et réseaux. Il s'interroge sur les solutions.

Août 2008 : Lors de la conférence Agile de Toronto, le développeur Andrew Shafer propose une conférence " Agile Infrastructure " : Patrick Debois sera le seul présent dans la salle. Andrew Shafer ne se rendra finalement pas à sa propre conférence, et Patrick Debois décide d'avoir malgré tout une conversation entre 2 portes sur le sujet avec lui. Suite à leur entretien, ils forment " Agile Systems Administration Group ".

Juin 2009 : Lors du velocity O'Reilly, John Allspaw et Paul Hammond donneront une conférence : 10+ Deploys a Day: Dev and Ops Cooperation at Flickr. Une conférence - devenue célèbre- sous forme de retour d'expérience, à travers le projet FlickR, vantant les bénéfices productifs de la collaboration entre les Dev et les Ops. Patrick Debois n'ayant pas pu assister à la conférence s'en lamente sur Twitter . Paul Nasrat lui retweet : " Why not organize your own Velocity event in Belgium? "

Octobre 2009 : L'idée est lancée, l'événement s'organise. Mais tout d'abord il lui faut un nom : Patrick Debois décide de prendre les 3 premières lettres du développement et des opérations (operationnals = admin' sys'), et rajoute le mot " jours " : la conférence " DevOpsDays " est née. Cette conférence du 30 octobre prend une dimension impressionnante : malgré la fin de l'événement la conversation se poursuit sur Twitter autour du hastag #DevOps. Le mouvement DevOps est officiellement lancé.
Lors d'une interview Patrick Debois avoue qu'il n'avait pas planifié que le mouvement s'appellerait DevOps mais qu'il avait choisi ce terme car " Agile Administration System " était trop long. "There never was a grand plan for DevOps as a word."
Aujourd'hui : Le mouvement DevOps a pris de l'ampleur, et ne cesse de croitre. Cette nouvelle façon d'envisager le travail commence à s'étendre aux organisations de la rigueur ... Et plus d'une trentaine de conférence #DevOpsDays ont déjà été organisées dans le monde, et cela n'est pas prêt de s'arrêter.

Source texte : The Incredible True Story of How DevOps Got Its Name - Fredric Paul dans Newsrelic Source illustration : What Is DevOps ? - Damon Edwards dans Dev2ops.org

# data[].attributes.attachment_link.title
Il était une fois l'origine du mouvement DevOps

# data[].attributes.attachment_link.description
Beaucoup d'entreprises sont en train d'effectuer des virages numériques. Cette révolution digitale implique souvent une réorganisation de la DSI " cheville ouvrière " ou " consultant technique " de l'accompagnement au changement de l'entreprise. Le terme DevOps est souvent lâché comme solution miracle.

# data[].attributes.body
Devops

# data[].attributes.attachment_link.description
Ce parcours vous permet de d'acquérir les notions et les outils indispensables pour comprendre le rôle de Product Owner...

# data[].attributes.attachment_link.readable_text
De nos jours, tout évolue de plus en plus vite. Les applications existantes doivent constamment être adaptées, à un rythme toujours plus accru. Des complications apparaissent en outre souvent entre les développeurs et les équipes opérationnelles. L'approche DevOps permet heureusement de pallier ces problèmes. Mais en quoi consiste-t-elle au juste ? Et à quel point est-elle importante pour votre entreprise ?

Comment l'approche DevOps est-elle née ?

Plus qu'une méthodologie pour le développement de logiciels, DevOps est une culture, qui est nécessaire pour pouvoir répondre aux besoins actuels des entreprises dans le cadre du développement de logiciels, de sites web, d'applications, etc.

Dans le modèle en cascade traditionnel, les exigences posées pour un logiciel étaient claires et soigneusement définies à l'avance. La définition du produit même était également stable. Les développeurs se chargeaient du codage du logiciel, et les équipes opérationnelles devaient ensuite le mettre en œuvre sur les systèmes de l'entreprise ou le web.

Mais le monde de l'informatique évolue de plus en plus vite. Les exigences changent sans cesse, et le développement des logiciels doit lui aussi être de plus en plus rapide. Les logiciels et les applications web doivent non seulement pouvoir être mis sur le marché plus rapidement, mais ils doivent aussi pouvoir être constamment adaptés. De nouvelles fonctions doivent pouvoir être ajoutées sans aucune difficulté, et les bugs découverts doivent pouvoir être corrigés. Tout cela a conduit au modèle de développement agile.

L'équipe de développeurs n'est cependant pas la seule à devoir réagir de manière rapide et efficace ; l'équipe opérationnelle, qui doit déployer et surveiller les nouvelles applications, doit elle aussi pouvoir le faire. Tout cela mène à une approche DevOps. Nombreux sont ceux qui associent ce terme à une collaboration plus étroite entre les développeurs, c'est-à-dire les concepteurs d'un produit, et les 'ops', c'est-à-dire l'équipe opérationnelle qui se charge de la publication, du déploiement, de l'exploitation et de la surveillance du logiciel.

Mais DevOps, c'est bien plus que cela - c'est un état d'esprit, une approche commune d'un problème. Une approche qui va au-delà de ce qui est de nature exclusivement technique ; une approche au sein de laquelle tous les niveaux de l'entreprise sont impliqués, y compris les départements chargés des finances et du marketing, et pour laquelle la communication est d'une importance vitale.

Tous (du développeur à l'administrateur systèmes, en passant par les personnes qui gèrent le réseau et les analystes d'affaires) font à présent partie de la même équipe. Et tous œuvrent dans un but commun : la réussite de l'entièreté du projet, et pas uniquement de leur partie.

Quels sont les principes de l'approche DevOps ?

Les silos traditionnels entre les développeurs, les testeurs, les responsables de la publication et les administrateurs systèmes sont abandonnés. Durant tout le processus de développement et de déploiement, tous collaborent plus étroitement, ce qui leur permet de mieux comprendre leurs questions et défis respectifs.

Les développeurs, par exemple, réfléchissent davantage à des aspects tels que les opérations, les sources, la disponibilité et la fiabilité. Ils peuvent p. ex. installer des interrupteurs qui permettent aux équipes ops d'activer/désactiver des fonctions, supprimer certaines options en cas de pic de trafic, etc. Les équipes ops assistent les développeurs en permettant de réaliser et surveiller des tests rapides, etc.

L'approche Devops requiert de ce fait des personnes possédant des compétences multidisciplinaires - des personnes qui connaissent bien tant l'infrastructure que la configuration, mais qui peuvent tout aussi bien réaliser des tests et déboguer des logiciels. Les devops jettent des ponts, tout en ayant un pied dans chaque domaine. Ils sont, comme le dit si bien Stephen Nelson-Smith, des " ambassadeurs, des pacificateurs, des facilitateurs et de communicateurs ".

Lorsque toute l'équipe de projet est agile, du code pour p. ex. une nouvelle fonctionnalité ou la correction d'un bug peut être rapidement mis en production - ou annulé si nécessaire. Plus l'écart entre les versions successives est réduit, plus l'impact d'une éventuelle défaillance peut être minimisé : il s'agit de l'approche " fail fast, fail cheap ". Grâce à elle, les entreprises peuvent régulièrement innover - ce qui est surtout important pour les entreprises en ligne. Il paraît d'ailleurs qu'Amazon met en œuvre ou modifie du nouveau code toutes les 2 secondes !
L'approche DevOps a un impact sur l'entièreté du cycle de livraison d'un projet, dont :

Un délai de commercialisation plus rapide

Un taux d'échec plus faible pour les nouvelles versions

Un délai de production plus court entre les correctifs

Un délai de rétablissement plus court (en cas de plantage d'une nouvelle version)

En quoi consiste DevOps ?

Le logo de DevOps est le symbole de l'infini, ou plutôt : une activité continue. DevOps, c'est en effet :

Un développement constant

Des tests constants

Une intégration constante

Une mise en œuvre constante

Une surveillance constante

Dans le cycle de vie de DevOps, on passe de la phase de projet à la phase de surveillance, et à chaque fois un nouveau cycle redémarre dès que le précédent est terminé. La partie en bleu correspond à la phase de développement, tandis que la partie en jaune correspond à la partie opérationnelle, mais en raison de leur interaction constante, les deux parties finissent par se confondre.

Pour la DevOps Agile Skills Association, 6 principes régissent le développement d'une stratégie DevOps :

1. Travaillez selon une approche axée sur le client, avec de courtes périodes de retours donnés par de véritables clients et utilisateurs finaux.

2. Évitez le modèle en cascade où chaque département travaille séparément, sans avoir une vue d'ensemble, et préférez une entreprise où chacun partage un état d'esprit technique pour créer un produit qui fonctionne comme il se doit.

3. Organisez vos équipes de façon verticale, de façon à ce qu'elles puissent être responsables " from concept to grave".

4. Misez sur des profils polyvalents, qui travaillent en équipes autonomes, au sein desquelles ils peuvent se développer sur le plan personnel.

5. Apportez constamment des améliorations sur le plan de la rapidité, des coûts et du produit/service même.

6. Automatisez tout ce qui peut être automatisé, y compris l'infrastructure, en créant p. ex. des plateformes cloud de nouvelle génération, basées sur des conteneurs (infrastructure as code).

Quels sont les avantages de l'approche DevOps ?

Sur le plan humain, le changement de mentalité constitue bien entendu le principal avantage. L'approche DevOps permet une plus grande empathie entre les membres des équipes, et met un terme aux silos de type " us and them ", où les personnes sont méfiantes, voire parfois effrayées les unes par rapport aux autres.

Ce que l'approche DevOps apporte concrètement sur le plan professionnel est clairement expliqué dans le rapport intitulé " Puppet's State of DevOps ". Ce rapport annuel compare des entreprises qui adoptent des pratiques DevOps (entreprises à haut rendement) à des entreprises qui ne le font pas au niveau de la mise en œuvre du produit, de la loyauté du personnel, de la sécurité, etc. Le rapport de 2016 révèle notamment ceci :

Rendement informatique : les entreprises à haut rendement déploient 200 fois plus souvent, avec des délais de production 2.555 fois plus courts. Leurs délais de rétablissement sont 24 fois plus courts et elles enregistrent 3 fois moins d'échecs lors de modifications.

Loyauté du personnel : les employés des entreprises à haut rendement ont 2,2 fois plus tendance à considérer leur entreprise comme étant un bon employeur.

Utilisation du temps : Les entreprises à haut rendement passent 22 % moins de temps à s'occuper d'imprévus ou à devoir recommencer un travail. Elles peuvent ainsi consacrer 29 % de temps en plus à de nouvelles tâches, comme l'élaboration de nouvelles fonctionnalités.

Sécurité : 50 % moins de temps pour résoudre des problèmes de sécurité, du fait que l'information sur les objectifs en matière de sécurité est mieux intégrée dans le travail quotidien.

DevOps : par où commencer ?

Le développement d'une culture DevOps requiert de la planification. Voici quelques astuces qui peuvent vous aider à développer une mentalité DevOps :

Réfléchissez à la manière dont vous voulez que votre équipe web fonctionne sur une période de 12 à 18 mois.

Examinez vos méthodes de travail actuelles et demandez-vous (sans oublier d'également consulter votre équipe !) ce qui coince, et où sont les risques.

Laissez vos équipes s'exprimer : comment pensent-elles pouvoir améliorer les processus de façon réaliste ? Que pensent-elles d'impliquer des ops dans des projets dev ?

Déterminez qui, parmi les employés existants, est désireux d'acquérir de nouvelles compétences.

N'hésitez pas à partager vos conclusions et votre projet avec d'autres départements : des équipes polyvalentes peuvent être créées dans toute votre entreprise pour en améliorer le rendement !

Lorsque vous recrutez, veillez à cibler des DevOps polyvalents et offrez-leur la possibilité de continuer à se perfectionner.

L'approche DevOps est-elle adaptée à tout le monde ?

DevOps est une excellente approche pour les entreprises (en ligne) qui innovent sans cesse. Pour elles, le délai de commercialisation est nettement raccourci, ce qui constitue un sérieux avantage financier.

Mais si votre entreprise n'est pas dans ce cas, l'approche DevOps améliorera bien sûr la cohésion entre vos employés, mais il y a de fortes chances que votre entreprise survive même sans adopter cette culture. Si la seule application créée en interne ne sert qu'à noter les présences lors de réunions ou à planifier les jours de congé, il est inutile de la mettre à jour quotidiennement !

Est-ce que Combell a elle aussi adopté les principes DevOps ?

Certainement ! Cela fait déjà de nombreuses années que Combell adopte une stratégie DevOps, au sein de laquelle une équipe d'experts polyvalents adopte une approche multidisciplinaire de l'application du client durant les phases de développement, de déploiement et de suivi. C'est ainsi qu'il est possible d'obtenir des applications plus fiables et des délais de livraison plus rapides. Cette approche a en outre pu être optimisée grâce à la reprise de la société Openminds en 2016.

Avez-vous vous-même un projet en chantier ? Ou voulez-vous développer votre projet actuel ? Discutez-en avec nous ! Nos équipes réfléchiront avec vous et détermineront ce dont vous avez réellement besoin en termes d'hébergement et d'équipements pour concrétiser le projet de vos rêves !

agile computing, délai de commercialisation, delivery pipeline, DevOps, docker, jenkins, puppet, stratégie DevOps

# data[].attributes.attachment_link.title
Qu'est-ce que DevOps et pourquoi ce mouvement est-il si important ?

# data[].attributes.attachment_link.description
De nos jours, tout évolue de plus en plus vite. Les applications existantes doivent constamment être adaptées, à un rythme toujours plus accru. Des complications apparaissent en outre souvent entre les développeurs et les équipes opérationnelles. L'approche DevOps permet heureusement de pallier ces problèmes. Mais en quoi consiste-t-elle au juste ?

# data[].attributes.attachment_link.readable_text
Pourquoi l'entreprise nécessite-t-elle une informatique agile, à même de proposer des applications qui s'adaptent au plus vite aux évolutions de ses métiers ? Finalement, on est en droit de se poser la question.

Mettre un frein final à la course à l'échalote

Avec la conception d'application selon des cycles en V (ou la lettre de votre choix), il s'agit pour la DSI de remettre sur l'ouvrage toute l'application, après une étude fonctionnelle poussée. L'étape suivante consiste à concevoir le nouveau code afin de générer une application (généralement très modifiée, parfois totalement refondue). Après tous les tests de ce nouveau code, le déploiement intervient entre six et 24 mois après la définition des besoins par les utilisateurs finaux. Résultats : les directions opérationnelles disposent enfin de l'application répondant bien aux besoins... qu'elles ont exprimés plusieurs mois auparavant. Quelques semaines après, on repart dans un cycle de plusieurs mois... Bref : le temps de mettre l'application à disposition, les besoins ont généralement évolué !

D'où la nécessité d'une méthode permettant, dans un premier temps, de concevoir et de déployer rapidement une application de qualité, puis de faire en sorte que des modifications plus ou moins importantes puissent être disponibles en quelques heures ou quelques jours. Cette différenciation ne justifie-t-elle pas à elle seule l'intérêt pour le DevOps ? Le déploiement rapide de la stratégie de l'entreprise et de ses évolutions n'incarne-t-il pas la méthode applicative idéale ? Certes, il faut prendre en compte le terrain psychologique des équipes de développement et de production, ainsi que le besoin de faire évoluer leurs modes de travail et leurs habitudes. Néanmoins, si l'informatique pouvait arrêter de courir après l'organisation sans jamais la rattraper...

Transformation numérique, time-to-market et agilité

Une étude IDC/Automic sur le DevOps a été réalisée au second semestre 2015 auprès de 201 entreprises françaises. Parmi les résultats, on constate que pour 52% des entreprises interrogées, " la transformation numérique " est la principale raison invoquée pour l'adoption d'une approche DevOps. Rien d'étonnant lorsqu'on sait que ces méthodes font les jours heureux des géants du Web, et que les entreprises ont pris conscience de la nécessité de passer à l'ère numérique (ou digitale).

Par ailleurs, 44% de ces entreprises avaient déjà initié une approche DevOps ou l'avaient planifié. Et deux tiers d'entre elles étaient motivés par des enjeux de digitalisation incontournable pour leurs activités. L'étude détaille ainsi que 21% des sondées mettent en avant le contexte de leur marché, 21% le time-to-market, et 19% le besoin en développement agile. Le " contexte de leur marché " englobe évidemment les contraintes réglementaires qui évoluent à rythme effréné. Or, pour les intégrer, l'approche traditionnelle s'avère inappropriée, puisqu'une mise à jour continue des règles impactant souvent plusieurs processus s'impose désormais.

Non seulement la démarche DevOps accélère la livraison des applications et (dans son stade avancé) la mise place des modifications en continu, mais en plus, elle offre une visibilité des processus et des transactions évoluées ainsi qu'une traçabilité des actions et des opérations. Encore un avantage au service des audits de plus en plus exigeants sur tous ces aspects.

C'est donc sans surprise que l'étude IDC révèle que 51% des grandes entreprises avaient déployé des méthodes agiles (fin 2015), et que 65% d'entre elles s'étaient alors tournée vers le DevOps. 71% des entreprises concernées témoignent d'une meilleure collaboration avec les métiers. Enfin, dans ces projets DevOps, 70% des indicateurs partagés le sont avec les directions opérationnelles.

Autre avantage du DevOps, une forte automatisation oblige l'entreprise à réfléchir sur les processus et les rôles de chacun. Alors, une bonne gouvernance devient indispensable. Or justement, de plus en plus d'entreprises adoptent des solutions de type ITMS pour maîtriser les processus, automatiser, redéfinir précisément les rôles. Tout cela n'est-il pas finalement complémentaire ?

# data[].attributes.attachment_link.title
Pourquoi les entreprises adoptent-elles une approche DevOps ?

# data[].attributes.attachment_link.description
Pourquoi l'entreprise nécessite-t-elle une informatique agile, à même de proposer des applications qui s'adaptent au plus vite aux évolutions de ses métiers ? Finalement, on est en droit de se poser la question. Avec la conception d'application selon des cycles en V (ou la lettre de votre choix), il s'agit pour la DSI de remettre sur l'ouvrage toute l'application, après une étude fonctionnelle poussée.

# data[].attributes.attachment_link.description
La plateforme cloud-native de Pivotal s'impose comme une force d'innovation logicielle pour les plus grandes marques internationales. Chaque jour, les millions de développeurs des communautés open source du monde entier permettent à nos technologies d'atteindre des milliards d'utilisateurs. Pendant plus d'une décennie, Pivotal a su insuffler la culture du développement logiciel chez les plus grands groupes de la Silicon Valley.

# data[].attributes.attachment_link.readable_text
Diffuser les connaissances et l'innovation dans le développement logiciel d'entreprise

Bio Alain Delafosse est consultant chez Objet Direct et Directeur Technique de KelKoo. Eric Mattern est Manager Open Source chez Objet Direct.

Cette conférence réunit des participants et des conférenciers venus du monde entier autour d'un sujet commun: la culture "DevOps":, ses techniques et ses bonnes pratiques. Le format de la conférence est simple: présentations le matin, et mini-sessions d'échange avec la méthodologie open space l'après midi.

# data[].attributes.attachment_link.keywords[]
interview alain delafosse et eric mattern

# data[].attributes.attachment_link.title
La transition vers une équipe DevOps par Alain Delafosse et Eric Mattern

# data[].attributes.attachment_link.description
Diffuser les connaissances et l'innovation dans le développement logiciel d'entreprise Bio Alain Delafosse est consultant chez Objet Direct et Directeur Technique de KelKoo. Eric Mattern est Manager Open Source chez Objet Direct. Cette conférence réunit des participants et des conférenciers venus du monde entier autour d'un sujet commun: la culture "DevOps":, ses techniques et ses bonnes pratiques.

# data[].attributes.attachment_link.title
Comprendre la loi de Conway pour réussir sa transformation DevOps (Clément Rochas)

# data[].attributes.attachment_link.readable_text
L'étymologie de DevOps prend son origine dans la contraction des mots " Développement " et " Opérations " qui vise à rapprocher développeurs et équipes de production.

S'il faut le rappeler, l'étymologie de DevOps prend son origine dans la contraction des mots "Développement" et "Opérations" qui vise à rapprocher développeurs et équipes de production dans une démarche plus agile, s'appuyant sur des processus plus fluides. Le principe DevOps a été présenté pour la première fois par le belge Patrick Debois, lors d'une conférence en octobre 2009. Administrateur système et consultant, l'homme s'était interrogé sur une démarche agile après avoir réalisé une mission de migration de données pour le Gouvernement belge durant laquelle les relations entre développeurs et administrateurs système s'étaient révélées complexes. Dans un contexte de grandes mutations économiques centrées sur le numérique, les directions informatiques mettent désormais leurs espoirs dans le DevOps pour tenir la cadence de livraison des nouveaux projets telle qu'attendue par les directions métiers.

La transformation numérique est là, et elle n'attend pas. Pour bien s'en rendre compte, il faut réaliser que le leader mondial des taxis ne possède pas de voitures ( Uber), que la banque en plus forte croissance n'a pas d'argent ( SocietyOne) et que le plus grand diffuseur de films au monde n'a pas de salles de cinéma ( Netflix). Un nouveau type de concurrence est en train de bouleverser toutes les règles du jeu établies. Aussi, quel que soit le domaine d'industries ou de services, les entreprises n'ont d'autre choix que de se moderniser pour tenter d'échapper au syndrome de " l'Uberisation ".

De nombreuses directions informatiques s'attachent donc à repenser leurs modèles de fonctionnement pour devenir plus rapides, plus flexibles et améliorer leur sacro-saint " Time to Market ". Selon une enquête IDC pour Automic de décembre 2015, ce sont près de 50% des entreprises françaises interrogées qui ont lancé, ou vont lancer une initiative DevOps. Et plus de 70% d'entre elles sont principalement motivées par les enjeux de la transformation numérique auxquels elles font face.

Pour autant, si le DevOps peut être considéré comme le moteur du succès chez nombre de nouveaux acteurs, sa généralisation, dans l'optique de " l'entreprise agile ", reste encore un véritable challenge pour la plupart des organisations traditionnelles. Ces dernières sont, en effet, confrontées à un problème d'informatique à deux vitesses pour lequel elles doivent revoir les fondements de leurs outillages, de leurs méthodes et faire évoluer les états d'esprit. C'est donc tout un nouvel écosystème qui se construit en périphérie de DevOps, notamment autour de l'automatisation et du conseil en organisation. Gartner prévoit d'ailleurs des volumes de marché supérieurs à 2,5 milliards de dollars sur ce segment d'activité actuellement très prisé par les capitaux-risqueurs.

L'automatisation au cœur des initiatives DevOps

Les applications sont devenues la composante essentielle de l'innovation et de la compétitivité des entreprises. Les équipes informatiques doivent donc délivrer en continu de nouvelles fonctionnalités répondant aux besoins des métiers, sans dégrader les niveaux de service, ni mettre en danger la sécurité et l'intégrité des systèmes.

Une étude IDC réalisée en avril 2015, montrait déjà que pour 60% d'entreprises américaines (Fortune 100), l'automatisation est la première étape d'une démarche DevOps. L'enquête IDC pour Automic confirme que c'est également le cas en France. En outre, elle met en lumière que les entreprises ne souhaitent pas remplacer leur patrimoine applicatif pour implémenter DevOps, mais au contraire, pour 69% d'entre elles, l'exploiter pour optimiser leur processus. Et ce sont 48% des entreprises, ayant déjà lancé leur initiative DevOps, qui se sont tournées vers des solutions d'automatisation.

Le développement agile, désormais largement adopté, est généralement accompagné d'un niveau d'automatisation suffisant pour permettre l'intégration continue - notamment avec des outils tels que Jenkins. Pourtant le succès d'une initiative DevOps requiert des niveaux d'automatisation encore plus poussés autorisant le test continu et le déploiement continu pour atteindre réellement le graal de DevOps consistant en la livraison continue des applications.

Netflix, Amazon... et Singapore Power adeptes du DevOps

Des entreprises telles que Netflix ou Amazon, locomotives de DevOps, ont construit leurs activités, et une bonne partie de leur succès sur une automatisation systématique de leurs processus. Chez Netflix, le déploiement est totalement automatisé, depuis le packaging du nouveau code jusqu'à la mise en production, en passant par le provisionnement de l'infrastructure virtuelle et les tests fonctionnels. Une nouvelle version d'application sera promue automatiquement dans une nouvelle infrastructure virtuelle et mise en service en lui redirigeant un sous-ensemble du trafic utilisateur. Après une phase de monitoring automatisé, si le comportement s'avère satisfaisant, la totalité du trafic est redirigée et l'ancienne instance de l'application et son infrastructure sont automatiquement décommissionées.

L'automatisation de la chaîne de livraison applicative, n'est néanmoins pas réservée aux entreprises partant de zéro ou faisant table rase de leurs investissements antérieurs. C'est le cas notamment de Singapore Power, qui est l'un des plus grands fournisseurs d'électricité et de gaz en Asie Pacifique. Leurs applications sous SAP étant critiques, le déploiement manuel de chaque nouvelle fonctionnalité constitue un risque considérable pour la société, risque constituant un frein au potentiel d'innovation. Le fournisseur d'énergie décide donc de standardiser et de sécuriser son processus de déploiement applicatif en automatisant l'ensemble des étapes. Ceci lui permet de supprimer les erreurs de coordination et d'accélérer le processus de livraison de plus de 90%, tout en réduisant le niveau de stress des équipes. L'entreprise obtient également un bénéfice indirect, grâce à un processus de déploiement désormais parfaitement auditable, renforçant la conformité de ses opérations informatiques aux réglementations en usage dans le secteur de l'énergie.

Bien qu'essentielle, l'automatisation des processus ne peut assurer à elle seule le succès d'une initiative DevOps. Ce genre de transformation se confronte immanquablement au décalage qui subsiste entre les équipes de développement et les équipes d'exploitation. Il s'agit d'une difficulté parfaitement illustrée par certaines différences fondamentales entre la culture agile et la boucle d'amélioration continue prônée par

Quel cadre pour mettre en place DevOps ?

DevOps est une philosophie basée sur le partage, la collaboration, la mesure et l'automatisation. Adopter une nouvelle culture impose une transition coordonnée. La technologie, l'organisation et l'environnement de travail constituent un contexte dans lequel DevOps devra s'intégrer en évitant de perturber les services existants et les applications en place. DevOps c'est également un nouvel état d'esprit. Aussi, il est normal de constater des freins organisationnels et culturels. Comme pour toute évolution profonde, l'implémentation d'une approche DevOps nécessitera un plan d'accompagnement du changement.

Pour cela il est primordial d'avoir l'appui du management et de constituer des équipes dédiées. Les résultats de l'enquête IDC pour Automic, montrent que c'est le cas pour les deux tiers des entreprises engagées dans une initiative DevOps. En effet, nouvelle façon de travailler, évolution des compétences et nouveaux outils peuvent freiner son adoption. Pour éviter cet écueil, il est recommandé d'impliquer la direction générale car elle est la seule à disposer de la légitimité nécessaire pour fédérer l'ensemble des participants autour d'un tel projet.

En outre, il convient d'intégrer les parties prenantes au projet applicatif telles que les équipes en charge des tests, celles en charge de la sécurité informatique, ou encore les personnes qui s'occupent des déploiements applicatifs. L'étude IDC révèle que 71% des entreprises ayant initié une démarche DevOps reconnaissent l'impact positif d'une telle collaboration entre les équipes IT opérationnelles.

Enfin, il reste nécessaire d'impliquer les directions métiers, et dans cet objectif de mettre en place un référentiel d'indicateurs de performance partagés comme le TRS par exemple. L'établissement d'une communication transparente vis-à-vis des métiers est en effet un facteur de succès pour 43% des entreprises en phase opérationnelle.

Pour conclure... automatisation, cadence, traçabilité, vitesse, rendement. DevOps et la transformation numérique risquent de résonner fortement aux oreilles des professionnels de l'industrie. Comme l'a fort bien illustré Gene Kim dans 'The Phoenix Project', après trois révolutions, l'industrie a encore probablement beaucoup à apprendre à l'IT.

Yann Guernion, product marketing director d'Automic, éditeur d'applications d'automatisation.

# data[].attributes.attachment_link.title
DevOps ou comment réussir sa transformation numérique

# data[].attributes.attachment_link.description
S'il faut le rappeler, l'étymologie de DevOps prend son origine dans la contraction des mots "Développement" et "Opérations" qui vise à rapprocher développeurs et équipes de production dans une démarche plus agile, s'appuyant sur des processus plus fluides. Le principe DevOps a été présenté pour la première fois par le belge Patrick Debois, lors d'une conférence en octobre 2009.

# data[].attributes.attachment_link.title
Conférence MSIT 2016 [DEVOPS] : DevOps et transformation digitale par Samuel Metias

# data[].attributes.attachment_link.readable_text
Pourquoi les pratiques agiles et le DevOps riment avec succès, amélioration de l'expérience client et hausse des activités ?

Le succès de la transformation digitale passe par les pratiques agiles et le DevOps, et la France n'est pas en retard, puisque 87% des entreprises françaises les considèrent comme prioritaires. Les services financiers et clients sont déjà précurseurs sur le sujet.

Il n'est pas trop tard pour prendre le virage de l'agilité, renforcer la satisfaction client et éliminer les silos, découvrons quelques chiffres et 3 recommandations clés.
Intégrer un nouveau modèle
Pour proposer une expérience numérique unique, il faut intégrer un nouveau modèle et pour cela

- positionner les logiciels au cœur des activités

- prendre en compte régulièrement des retours clients l ors du cycle développement

- favoriser la collaboration entre équipes de développement et production
Mesurer l'impact du DevOps et des pratiques agiles
Mettre en place ces méthodes implique de mesurer régulièrement leur impact grâce à une sélection d'indicateurs clés de performances livrant des informations sur

- le rendement : amélioration du rendement par les pratiques agiles (39 % - France) et par le DevOps (42%)

- la productivité des collaborateurs : les pratiques agiles augmentent la productivité des employés (44 % - France) et le DevOps (43 %)

- les délais de commercialisation des produits : diminution de la durée de développement et de lancement de nouveaux produits (pratiques agiles, 24 %)

- les délais des nouvelles applications : diminution du temps pour le développement et lancement de nouvelles applications (DevOps, 38%)

- la croissance des activités : réduction du temps pour saisir de nouvelles opportunités (pratiques agiles, 27%)
Combiner Agile et DevOps
La complémentarité des deux méthodologies permet d'optimiser les résultats. Ainsi, la combinaison des deux démarches

- améliore fortement l' expérience client selon 83% des utilisateurs

- fournit de bons indicateurs en termes d' efficacité

- booste les nouvelles activités (+38% - EMEA) et le rendement (+23% - EMEA)

DevOps permet de profiter plus rapidement des bénéfices du développement agile.
Etude CA Technologies (novembre 2016) menée par Coleman Parkes auprès de 1 770 dirigeants et responsables informatiques de grandes entreprises dans 21 pays et 10 secteurs d'activités.

# data[].attributes.attachment_link.title
DevOps et Agile : le duo de la transformation numérique | iTPro.fr

# data[].attributes.attachment_link.description
Pourquoi les pratiques agiles et le DevOps riment avec succès, amélioration de l'expérience client et hausse des activités ? Le succès de la transformation digitale passe par les pratiques agiles et le DevOps, et la France n'est pas en retard, puisque 87% des entreprises françaises les considèrent comme prioritaires.

# data[].attributes.attachment_link.readable_text
Répondre aux besoins des métiers, améliorer la qualité des applications et accélérer leur disponibilité sur le marché sont les trois principaux enjeux des DSI pour accompagner la transformation numérique de leur entreprise. Un projet qui implique de repenser leur organisation pour acquérir davantage d'agilité dans la conception et la mise en production des applications. Et c'est précisément l'objectif fixé par la démarche DevOps.

Comment ? En rapprochant les développeurs, chargés de leur création, des opérations qui assurent leur mise en production.

Aligner les objectifs des développeurs et des opérations, tout en accélérant la mise à disposition de nouvelles fonctionnalités logicielles pour nos clients, c'est l'un des objectifs du continous delivery. La mise en place d'une telle méthode implique une adaptation de l'organisation et une automatisation de l'infrastructure poussée à l'extrême.
Un projet de conduite du changement
Cette culture collaborative dépasse le cadre de la DSI. Elle implique aussi les métiers qui y sont associés tout au long du processus : de la définition du besoin en amont et dans le cycle des itérations successives pour valider que les fonctionnalités répondent au cahier des charges fonctionnelles qu'ils ont fixé.

Selon IDC, ce " big bang " organisationnel a le vent en poupe. Une majorité d'entreprises considère le DevOps comme le meilleur moyen de lancer leur transformation numérique et 44% ont déjà engagé un tel projet ou envisage de le faire.

Mais si DevOps présente un fort enjeu de conduite du changement au sein de l'entreprise, il s'appuie aussi sur des choix techniques. On a tendance à se focaliser sur les outils de développement et les méthodes de management agiles (comme Scrum), mais l'infrastructure est un point essentiel.

Avec DevOps, l'infrastructure devient une commodité pour les développeurs qui ont ainsi la possibilité de l'utiliser en mode self-service au travers d'API ou de routines logicielles. On parle bien d'infrastructure as a code. Pour les opérations, ces infrastructures doivent pour autant conserver leurs caractéristiques de robustesse, de performance et de coût. Par exemple, un développeur provisionne un environnement de développement complet ou un sandbox de qualification en quelques minutes. Il peut le générer quelle que soit sa localisation et sans consommer un seul octet au démarrage, voilà une réponse aux enjeux d'un projet DevOps. C'est ce que nous faisons avec CodeEasy.
CodeEasy, le projet DevOps de NetApp
Acteur mondial du stockage et du management des données, NetApp pratique le DevOps pour le développement de ses solutions. " CodeEasy est un environnement interne qui automatise le processus de provisionnement des espaces de travail de développement et de QA. Cet outil est utilisé par une communauté de plus de 2 000 développeurs à travers le monde. Nous exploitons nos propres technologies, notamment clustered Data ONTAP" indique Kumaraswamy Namburu, Responsable du release engineering chez NetApp.

Pour l'entreprise de Sunnyvale, DevOps remplit le double objectif d'améliorer la qualité du code de ses développeurs et d'accélérer le " time to market " pour ses solutions.

Si nous n'avions pas changé nos méthodes, nous n'aurions sans doute pas pu respecter les délais de notre calendrier ambitieux. Par exemple, en exécutant un script CodeEasy, un développeur peut dupliquer n'importe quel environnement et obtenir un sandbox de QA ou de développement complet avec une empreinte nulle sur le système de stockage. Il peut ensuite répliquer l'environnement dans d'autres sites à travers le monde, afin de le mettre à disposition à d'autres développeurs.

______
Jérôme Fournier est Manager Avant-vente Grands comptes chez NetApp France.

# data[].attributes.attachment_link.title
DevOps : un maillon essentiel de la transformation numérique Jérôme Fournier, NetApp

# data[].attributes.attachment_link.description
Répondre aux besoins des métiers, améliorer la qualité des applications et accélérer leur disponibilité sur le marché sont les trois principaux enjeux des DSI pour accompagner la transformation numérique de leur entreprise. Un projet qui implique de repenser leur organisation pour acquérir davantage d'agilité dans la

# data[].attributes.attachment_link.readable_text
5 conseils pour réussir votre transformation DevOps

Savez-vous faire du DevOps à la mode, à la mode ? La mode n'est pas toujours à la nouveauté ! Si le terme DevOps a vu le jour dans les années 2000, ce n'est que courant 2014 que le mouvement a réellement pris de l'ampleur. Aujourd'hui, de plus en plus d'initiatives se créent autour du sujet (meetup et conférences) et bon nombre d'entreprises se lancent dans cette transformation à la fois technologique et organisationnelle. Le DevOps est partout et vient jusqu'à s'immiscer dans les intitulés de poste.

Si comme Woody, l'adoption de la culture DevOps au sein de votre organisation vous interroge et peut-être même vous effraye, vous trouverez dans cet article, je l'espère, quelques réponses sur les bonnes comme les mauvaises pratiques et la réalité du terrain.

L'année dernière, j'ai intégré une équipe composée de Devs (organisés suivant la méthode Agile) et d'Ops, avec pour objectif le lancement d'une nouvelle plateforme web chez un grand industriel français. J'ai alors découvert les enjeux du DevOps et je me suis confrontée aux difficultés de sa mise en place. De cette expérience, j'ai retenu 5 points essentiels à la réussite d'un tel projet.

1 - Pas de DevOps sans automatisation

Le DevOps a été pensé pour réduire le "time-to-market", c'est-à-dire diminuer le temps de livraison des applications et des services informatiques, et donc d'accroître sa compétitivité sur le marché.

Pour s'inscrire dans cette dynamique, notre équipe avait pour but de réaliser au moins une mise en production par jour. En d'autres termes, nous devions être capable de dérouler chaque jour le cycle de vie complet d'une application : planification, code, test, release, déploiement, opération et supervision. C'est bien sûr ici qu'entrent en jeu l'automatisation et la chasse aux actions manuelles chronophages, rébarbatives et qui sont autant de sources d'erreur et de retards dans les déploiements.

Pour relever ce challenge, nous avons fait les choix techniques suivants :

Hébergement de la plateforme web dans le Cloud AWS, afin de bénéficier de la scalabilité et tout particulièrement de l'automatisation de la plateforme grâce aux nombreuses APIs. On parle d'infrastructure programmable ou d'Infrastructure as Code.

Architecture Blue-Green afin de déployer en production sans downtime et d'opérer un roll-back en quelques secondes si nécessaire.

Architecture applicative distribuée en micro-services pour faciliter les déploiements. En effet, chaque micro-service étant une application à part entière possédant son propre code source et sa propre infrastructure (serveurs et base de donnée), peut être déployé indépendamment des autres.

3 environnements :

L'UAT pour la validation fonctionnelle par les product owners. Il s'agit d'une seule machine virtuelle faisant tourner toutes les briques de l'application dans des containers Docker.

La pre-prod pour la validation technique, c'est-à-dire s'assurer que le code va correctement tourner sur une infrastructure telle qu'elle sera en production. Cette fois, chaque composant tourne sur ses propres machines virtuelles et non plus dans des containers.

La production, environnement iso à la pre-prod à l'exception d'un composant additionnel : Cloudfront, service de Content Delivery Network pour améliorer la performance du site et l'expérience utilisateur.

Automatisation des tests et des déploiements du code dans les différents environnements par les outils suivants:

qui propose une couche d'abstraction supplémentaire aux APIs du cloud. Il permet de gérer tous types de ressources AWS (machines virtuelles, bases de données, alertes de monitoring, comptes utilisateur, etc...) via de simples fichiers de configuration.

qui permet la création d'images de machine AWS. Pour limiter les phénomènes de dérive dans le temps, nous travaillons sur des images immuables, c'est à dire que nous générons des images de machines qui ne sont plus modifiées (pas de patch OS par exemple) et qui sont les mêmes en preprod et en prod.

qui offre une rapidité de déploiement en un temps record (création d'image et déploiement en seulement 2 à 3 minutes).

Travis qui fait tourner les tests unitaires à chaque nouveau commit et qui déclenche les scripts de déploiement.

Github pour le versioning du code aussi bien applicatif que lié à l'infrastructure.

Le schéma ci-dessous décrit notre workflow global de déploiement :

Travis automatise le déploiement en UAT et en pre-prod. Quant au déploiement en production, il est réalisé par les Ops via un script Python qui demande validation à chaque étape critique du déploiement (création des machines via Terraform, mise à jour de l'API Manager, migration des schémas de base de données, vidage du cache, bascule DNS vers la nouvelle stack blue ou green). Ainsi, les Ops gardent le contrôle sur le déploiement en production en cas de problème.

2 - Attention, les outils ne sont pas la solution miracle

Si, sans nul doute, l'automatisation passe par l'outillage, les outils ne sont toutefois pas la solution miracle. Un outil mal maîtrisé ou encore mal implémenté, pourra mettre vos objectifs en péril. Nous en avons fait les frais !

Au lancement du projet, l'équipe de développeurs était composée de 3 développeurs pour un Product Owner. Le workflow git se voulait donc simple :

Cependant, au fil des mois, l'équipe a triplé de volume : 10 développeurs organisés en 3 sous-équipes avec chacune un product owner travaillant dans des pays différents. Entre décalage horaire et dépendance entre les équipes, il a rapidement été très compliqué d'obtenir un branche staging "ready for prod", c'est-à-dire ne contenant que des features validées par les product owners. Ce workflow git inadapté a lourdement entravé nos mises en production quotidiennes.

Face à ces nouvelles contraintes, l'évolution de notre workflow git a été nécessaire :

Les outils doivent répondre à des contraintes et à des besoins précis, propres à votre organisation.

3 - Devs comme Ops, maîtrisez l'infrastructure

L'architecture Cloud vient casser le modèle des infrastructures traditionnelles on-premise. La contrainte majeure du Cloud est le taux de disponibilité des machines: 99%. Cela semble peut-être anodin au premier abord. Cependant, comprenez bien que pour une application tournant sur 20 machines avec une disponibilité de 99%, sa disponibilité globale sera seulement de 80% (0.99^20).

Cette nouvelle contrainte oblige donc à repenser les infrastructures pour assurer la haute disponibilité des services. Si des mécanismes comme l'auto-scaling permettent de reconstruire automatiquement les machines indisponibles, il est également nécessaire que le code soit capable de subir cette perte de machine sans engendrer une dégradation voire une interruption du service (par exemple, pas de perte de session utilisateur lors d'un crash de machine). Dans ce nouveau modèle, la résilience des applications est portée à la fois par l'infrastructure et le code applicatif. Ainsi, plus que jamais, il est essentiel que Devs et Ops collaborent étroitement.

En outre, dans notre cas, l'implémentation du blue-green impose un certain nombre de règles à respecter et de concepts à appréhender. Par exemple, pour faire fonctionner le blue-green avec une base de données mutualisée, il faut éviter les changements disruptifs de schéma de table comme le renommage ou la suppresion de colonne afin de garder la compatibilité des deux versions du code avec la base de données. Il est primordial que les développeurs assimilent ces nouvelles contraintes qui ont un impact direct sur leur stratégie de développement.

C'est pourquoi, il incombe aux Ops la responsabilité d'accompagner et de sensibiliser les Devs à ces changements par l'organisation de workshop technique et la rédaction de documentation par exemple.

4 - Devs et Ops, enterrez la hache de guerre

Les tensions entre Devs et Ops proviennent du fait qu'ils œuvrent à des fins contradictoires: si les Devs encouragent les changements pour répondre aux exigences métier, les Ops garant de la stabilité de l'infrastructure y sont réfractaires, toute release étant perçue comme un risque.

Tout l'enjeu du DevOps est de gommer ces divergences pour créer une équipe avec des indicateurs de résultat et un objectif commun : rendre possible le déploiement continu tout en maintenant une application stable. Techniquement parlant, cela se traduit par l'automatisation des tests et des déploiements qui permettent de fréquentes mises en production tout en limitant les risques.

N'oublions cependant pas une composante essentielle : l'humain ! C'est sans nul doute ce qu'il y a de plus difficile à changer : nos habitudes et nos réflexes nous empêchent de collaborer efficacement. Pour pouvoir changer nos automatismes, il faut tout d'abord en prendre conscience. Voici par exemple deux points sur lesquels j'ai travaillé :

Ne plus se rejeter la faute et se blâmer mutuellement pour rapidement réagir ensemble aux problèmes.

Faire l'effort d'intégrer les contraintes des uns et des autres et d'agir en conséquence.

Pour illustrer le dernier point, j'ai un jour poussé un changement un peu trop précipitamment sur l'environnement d'UAT. Malheureusement, cela a entraîné un downtime d'une heure, au moment précis où les products owners avaient prévu la validation des features. Avec mon regard d'Ops, je ne me suis pas préoccupée des conséquences : "L'UAT, ce n'est pas la prod, c'est pas grave !" ai-je pensé. Cependant, cela a eu un impact direct pour la productivité de l'équipe puisque que j'ai mis les développeurs en retard dans leur sprint.

5 - L'organisation est tout aussi importante que la technique

Pour une collaboration réussie entre Devs et Ops, il est indispensable de repenser l'organisation de l'équipe. Voici quelques astuces qui ont considérablement amélioré nos conditions de travail au quotidien :

Allouer 2 heures dédiées à la résolution de bugs en production par sprint et par équipe de développement. Les Ops n'auront plus à résoudre seuls les problèmes qui sont à 90% lié au code. Ils débuggeront côte à côte avec les Devs. L'esprit d'équipe renforcée et la confrontation des deux visions ne rendra que meilleure la réactivité face aux incidents. De plus, c'est un excellent exercice: les Ops comprendront davantage la façon dont est codée et construite l'application, puis les Devs appréhenderont mieux le fonctionnement de l'infrastructure.

Travailler dans le même open space pour faciliter la communication. Durant deux semaines, nous avons dû (Dev et Ops) travailler à des étages différents. Cela n'a l'air de rien, mais un étage a suffi pour dégrader la qualité de nos échanges.

Minimiser l'adhérence entre Dev et Ops par l'organisation de réunions hebdomadaires afin d'anticiper et de planifier les tâches liées à l'infrastructure. Ainsi, il pourra être décidé d'embarquer ou non un ticket dans le sprint selon la charge des Ops. Cela leur évitera de devoir traiter les demandes des Devs en urgence.

Enfin, le DevOps, à la fois challenge technique et humain, provoque la rupture avec l'ancien modèle de l'IT en silos. Soyez-en donc conscients, son adoption ne sera ni immédiate, ni réussie du premier coup. Mieux vaut d'ailleurs commencer sur un périmètre précis comme une application en particulier pour ensuite étendre la démarche. Pour réussir ce pari, placez-vous dans un mode d'amélioration continue et d'apprentissage. Osez l'échec pour mettre en place du DevOps à la mode de chez vous !

Ce retour d'expérience sera présenté lors du PHP Tour Nantes le 19 mai 2017 par Aurore Malherbes et Pauline Bourjot.

# data[].attributes.attachment_link.title
5 conseils pour réussir votre transformation DevOps -

# data[].attributes.attachment_link.description
5 conseils pour réussir votre transformation DevOps Savez-vous faire du DevOps à la mode, à la mode ? La mode n'est pas toujours à la nouveauté ! Si le terme DevOps a vu le jour dans les années 2000, ce n'est que courant 2014 que le mouvement a réellement pris de l'ampleur.

# data[].attributes.attachment_link.readable_text
Tribunes

Mise en oeuvre de la démarche DevOps

Bon nombre d'entreprises, françaises ou internationales, développent au sein de leur structure des démarches de DevOps, dont le marché devrait atteindre 2,3 milliards de dollars en 2015.

Qu'est-ce le DevOps ?

DevOps, concaténation du mot " Développement " et du mot " Operations ", pouvant être traduit en français par " production ", est un mouvement ayant fait son apparition en 2009. Le DevOps est aujourd'hui utilisé par près d'un quart des 2000 plus grandes organisations mondiales, avec pour objectif de promouvoir du mieux possible un travail commun entre les différentes parties prenantes d'un projet SI (notamment entre développeurs et chargés d'exploitation).

Ce mouvement trouve sa source dans le fort développement de l'entreprise numérique, nécessitant une révision des méthodes de création d'applications. L'apparition de nouvelles technologies, de nouveaux supports ainsi que de constantes évolutions réglementaires, obligent les acteurs du SI à s'adapter rapidement aux changements. La méthode Agile, permettant de répondre en partie à cette nécessité d'adaptation continue, est désormais entrée dans les moeurs, et ses avantages dans différents contextes ne font aujourd'hui plus débat. Si le développement logiciel a été à l'origine de l'émergence de l'agilité, il convient aujourd'hui d'exporter son mode de pensée aux autres acteurs du projet.
Dans ce contexte, mettre en place une politique d'agilité commune entre développeurs et exploitants apparaît non seulement bénéfique mais également nécessaire pour la DSI, se devant d'être modulable et réactive.

Le DevOps, plus une philosophie plus qu'une avancée technologique

Lorsque l'on évoque le DevOps, il est important de rappeler que ce dernier ne se définit pas comme étant novateur d'un point de vue technologique. Il n'est pas question ici d'implanter au sein de son organisation une méthode qui sera génératrice d'outils révolutionnaires. On parle ici plus d'une mise en valeur d'un mode de fonctionnement, d'une philosophie que d'une volonté de la part des décideurs d'implémenter un nombre considérable de nouveaux systèmes en interne.

Le DevOps s'appuie sur le principe suivant : le déploiement et l'exploitation d'un système d'information constituent des activités à part entière de son cycle de vie, et doivent in fine être considérées comme telles. De la même manière que la phase de codage d'une application s'inscrit dans une logique d'agilité, il convient de penser et d'agir de la sorte durant la phase finale du développement.
Via la mise en place de cette méthode, les entreprises voient là l'occasion de réduire les délais de mise à disposition des infrastructures. Pour ce faire deux leviers s'offrent à elles :
- Adapter le processus de mise en production, considéré par beaucoup comme trop contraignant,
- Favoriser la communication et la définition d'une trajectoire commune entre développeurs et exploitants.

A terme, le but est de définir des modes de fonctionnement communs entre les différents partis, basés sur les volontés de chacun : production régulière d'évolutions et réactivité côté développement, et stabilité de la production pour l'exploitation.

Réactivité et stabilité sont deux notions qu'il est difficile de combiner dans un contexte SI. Cependant, cette combinaison peut être accompagnée par l'automatisation des tâches récurrentes et sujettes aux erreurs humaines, notamment dans la préparation des plateformes de production. Via la mise en place de nouveaux outils, on pourra par exemple automatiser la configuration des serveurs, les déploiements d'applications critiques ou encore les différents tests d'infrastructures.

Réactivité, objectifs communs, automatisation et cohérence sont les maitres mots du DevOps, adoptée par beaucoup, et amenée très probablement à se développer pour à terme devenir la norme au sein des DSI.

Articles sur le même sujet

, dans

Tribunes

# data[].attributes.attachment_link.title
Le DevOps : un nouveau mode d'organisation pour les DSI

# data[].attributes.attachment_link.description
Tribunes Bon nombre d'entreprises, françaises ou internationales, développent au sein de leur structure des démarches de DevOps, dont le marché devrait atteindre 2,3 milliards de dollars en 2015. Qu'est-ce le DevOps ? DevOps, concaténation du mot " Développement " et du mot " Operations ", pouvant être traduit en français par " production ", est un mouvement ayant fait son apparition en 2009.