Dev opsday case study

1 035 vues

Publié le

DevOps Day (25 Novembre 2014) - Présentation d'une étude de cas => Transformation DevOps.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 035
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
18
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Dev opsday case study

  1. 1. Etude de cas - DevOps Michel PERFETTI Radoine DOUHOU
  2. 2. Une entreprise tout à fait (dans la) normale Il était une fois Contoso
  3. 3. Le contexte •L’offre: ▪Ventedeproduitsgénéralistes. •Lemarché: ▪Hyperconcurrentieletarrivéedegrosacteursétrangerssurunmarchémature. •Modededistribution: ▪Multicanal:réseaud’agencesetsiteeCommerce. •Objectif: ▪Développerdenouvellesoffresinnovantespourconfortersaplacesurlemarchéainsiquesesmarges. •Desired State Configuration.
  4. 4. Organisation des équipes Equipe de Dev ▪Organisation par «features». ▪Itérations plus courtes sur le cycle Dev RecUAT. ▪Mais le rythme de livraison en production n’a pas changé. Go Live One Shot. ▪Build et construction de packages automatisés. ▪Responsable de tous les environnements Hors-Prodavec des écarts d’architecture avec la Prod. Ops Métier Développement Scrum «but» Métier Développement Scrum «but» Métier Développement Scrum «but»
  5. 5. Organisation des équipes Ops:Equipe transverse au SI ▪Cisaillement des équipes par technologie et logiciels (SQL Server, Web, …). ▪Non localisé avec les équipes Métier et Dev. ▪Echange par ticketing. ▪Planification des release à minima 15 jours à l’avance. ▪Installation des releases en suivant des procédures faites par les équipes Dev. ▪Responsable des environnements de Pre-Prodet Prod. Ops Métier Développement Scrum «but» Métier Développement Scrum «but» Métier Développement Scrum «but»
  6. 6. Incentives des équipes Métier Développement Ops •Succèsdesfeaturesmisesenplaces. •Rapiditédemisesurlemarché •Qualité de code (nb de defectssur le code produit). •Respectsdesdélaisfournisparle«métier». •Disponibilitéetstabilitédel’application(infra+ code). •Délaiderésolutiondesincidents.
  7. 7. Points de souffrance: Métiers & Dev •Manquede visibilitésurles livraisons. •Tests difficiles. •Inertie des équipes DSI dans l’implémentation de nouvelles offres. •Difficiles calculs de ROI car manque de business KPI’sfiables. •Tentatives d’intégration d’appli SaaSlaborieuse par manque de communication entre fournisseur et DSI. Métier Dev •Validation des fonctionnalités •Besoinstrop complexes. •Une pression toujours plus forte du business face au Time To Market Dev Métier
  8. 8. Points de souffrance: Dev & Ops •Infrastructure opaque •Pas de communication directe •Incompréhension des besoins de développement •Délai de traitement DevOps •Pas de priorisation •Pas d’interlocuteur unique •Incompréhension des besoins de la production OpsDev
  9. 9. Points de souffrance: Ops& Métier •Communication inexistante •Métriques inutiles Métier Ops •Que de la communication de crise •Aucune information à donner OpsMétier
  10. 10. Nouveau projet ! •L’équipe Business souhaite lancer une nouvelle offre de livraison «par drone». Le délai de mise sur le marché sera très court malgré un challenge technologique important. •Comment une démarche DevOps sur plateforme Azure peut-elle aider l’entreprise à lancer cette nouvelle offre en rompant avec les souffrances habituellement rencontrées par les partie prenantes ?
  11. 11. Changement d’organisation Etape#1
  12. 12. Métier Scrum Changement d’organisationAméliorer la collaboration Dev & Ops DevOps Dev Ops •Dev : ▪Applicationplusrobuste:traces, casd’erreurstechniques ▪participationdesOpsauDesign. •Ops: ▪Meilleure réactivité face aux demandes des Dev. ▪Meilleure connaissance de l’application donc meilleur support. •Collaboration continue durant les différentes étapes du projet. •Incentives partagées.
  13. 13. Effetsvisés ▪Dev : Meilleure réactivité réciproque (Demande des Dev vers les Ops). ▪Ops: meilleure connaissance de l’appli donc meilleur support et anticipation. •Continuité, Qualité, délai améliorés. •Objectif communs, langage communs, outils communs.
  14. 14. Construction des environnements Etape#2
  15. 15. “Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources” Jesse Robins Capacitéàautomatiserlaconstructionetlemaintiend’environnementtechniqueenlescodant,réduisantainsilesdélaisdemiseàdispositionauxéquipes. Couts Délais Management + - Scalabilité Ressources - + Construction des environnementsDémarche Infrastructure As a Code
  16. 16. Construction des environnementsLe besoin d’environnements •Fournir des environnements pour : ▪les 3 développeurs qui seront sur le projet. ▪Stress & Load Test avec une configuration identique à l’environnement de Production •Etre en mesure de: ▪Provisionner un environnement de développement sans délai. ▪Deprovisionner,reprovisionnerles environnementsde Stress & Load Test lorsqu’il n’est pas utilisé.
  17. 17. Construction des environnementsAzure & DSC: bettertogether •Azure: ▪Provisioning de VM. ▪Scalabilité, Elasticité, Switch On/Off, Payas Use . •Desired State Configuration: ▪Automatisation la configuration logicielle et applicative des environnements. ▪Je souhaite: –IIS activé, –Visual Studio et SQL Server installés. –Mon site Web Contoso installé. –Ma BD Contoso installé.
  18. 18. Construction des environnementsLes apports pour notre projet 1 4 Les Dev ont leur environnement de Dev Jour J de leur arrivée. Un environnementde Load Test disponible et utilisable pour faire du TDD. 2 3 Une collaboration entre les Dev et Opspour coder une configuration iso-prodet réutilisable. DevOps Time To Marketaméliorée Qualité améliorée
  19. 19. Continuous Deployment Etape#3
  20. 20. Continuous delivery != Continuous deployment Spec Dev Tests Deploy Spec Dev Tests Deploy Continuous delivery Tâchemanuelle Continuous deployment Tâcheautomatique
  21. 21. Objectifs: livrerde la valeur“business” encontinue •Engranger du feedback •Eviter l’effet tunnel •Réduire les effets de bords •Réduire l’écart entre la spécification et la livraison •Livrermoinsde choses, maislivrerplus souvent Plus unechose estdifficile, plus ilfautla refairepour la rendresimple
  22. 22. Les Outils Besoin User Story Tâche Code Build Tests Déploiement Team Foundation Server / Visual Studio Online Release Management On vise: •La continuitédansles outils •La traçabilitéles changements
  23. 23. Build •Objectif : ▪Est-ceque logiciel compile? ▪Est-ce que les tests sont bons? ▪Comment évolue la qualité du code? •Gain : ▪Maitrise de la générationdes applications ▪Contrôlequalité au plus près des développeurs ▪Identification (et résolution) des problèmesau plus tôt ▪Feedbackrapide (en minutes) ▪Quality gates
  24. 24. Tests d’intégration •Objectif : ▪Passerle logiciel au banc d’essai ▪Valider les spécifications de façon automatique ▪Limiter l’interaction avec le métier sur les parties déjà testées •Gain : ▪Toutle monde se concentre sur le développement de nouvelles fonctionnalités ▪La validation est en partie réalisée par des tests automatisés ▪Gestiondes régressions (un bugun test une correction)
  25. 25. Déploiments automatisés •Objectif : ▪Identifier le pipeline de déploiementet les responsabilités ▪Etre sûr que le logiciel est toujours déployable ▪Déployer par petits incrémentspour éviter le Bing Bang •Gain : ▪Intervention humaine limitée à de la supervision ▪Opérations manuelles exceptionnelles ▪Traçabilité ▪Métriques (nombre de deployments, durées,…)
  26. 26. Tests de chargeLe besoin pour notre projet Spec Dev Tests Load Tests Deploy Performance Testing A quelle vitesse mon application va s’exécuter ? Load Testing Comment mon application se comporte en charge ? Stress Testing Quelle est le point de rupture de mon application ? Capacity Planning Mon application pourrait-elle être «scalé» pour supporter la charge future ? Cost estimation Quel sera le cout de mon application pour une charge donnée?
  27. 27. Tests de chargeVisual Studio Web Load Tests + VSO 1 Définition et implémentation des scénarii de tests Exécution des tests sur Azure via Visual Studio Online 2 3 Analyse des indicateurs de performance temps réel et génération de rapport à posteriori. 4 Identification des «bottlenecks» et optimisation
  28. 28. Tests de chargeVisual Studio Web Load Tests + VSO Web Test Load Test Application Insight Site Web Rapports SQL Azure Monitor
  29. 29. Monitoring Etape4
  30. 30. Monitoring projet •L’automatisation de la chaîne de création de valeur simplifie les estimations •2 stratégies en agilité dans la livraison de valeur: ▪Ecole itérative (Scrum): ratio valeur/effort (ROI) et vélocité ▪Ecole du flux (Kanban): Lead/Cycle time •Objectifs: répondre à ▪“En combien de temps une fonctionnalité sera livrée et à quel cout?” ▪“Quel budget pour terminer?”
  31. 31. Monitoring métier •Feedback généré à partir de l’usage du produit : ▪Le taux d’utilisation ▪Le taux de transfo ▪Segmentation client ▪A.K.A Google Analytics.+ Azure Application Insights:ajoutés par les dev dans le code •Nouvellespossibilités: ▪Canary ▪Tests A/B ▪Feature switch ▪HypothesisDriven Development
  32. 32. Performance et disponibilitéLe besoin pour notre projet •Suivi temps réel de la disponibilité de l’infrastructure: ▪Etre alerté si dépassement de seuils ou exceptions pouvant entrainer une indisponibilité. •Suivi temps réel de la performance de l’application: ▪Nombre d’utilisateurs. ▪Temps de réponse par page. ▪Décomposition des temps de traitement (Web vs Database). •Métriquesmétiers ajoutéespar les dev: ▪Produits les plus consultés. ▪Tauxde transformation.
  33. 33. Performance et disponibilitéSolution Microsoft Disponibilité Servers forwarding data through SCOM Windows & Linux Server Cloud Service Monitoring Azure Diagnostics On Prem IaaS PaaS Performance et usage : New Relic
  34. 34. Ca a l’air simple mais… Conclusion
  35. 35. DevOps: une démarche •Une mentalité, avant les outils. •Parties prenantes et pas d’exécutants: ▪la démarche doit faire sens. ▪Une organisation DevOps ne s’impose pas par la hiérarchie mais se construit avec les équipes ▪Une démarche qui fait sens est une démarche qui apporte de la valeur aux business, aux devet aux ops. ▪Leaders de pensée •Automatiser c’est: ▪Eliminer les tâches laborieuses ▪Fiabiliser les processus ▪Réaffecter les équipes dans des tâches de valeurs
  36. 36. DevOps: éviterles clichés •DevOps = on déménage •DevOps = on va réduire les équipes car on automatise •On passe en DevOps pour la prochaine release •Plus de système de ticket, on règle en direct les problemes •Tout le monde est Ops, tout le monde est Dev Les équipes sont parfois déjà dans le scepticisme après le passage en “agile”
  37. 37. Comment y aller ? Projet pilote ou transition incrémentale ?Ou un peu des deux? •Changement de paradigme/technologie (ex : passer d’une infra classique à Cloud Public, Mobilité) ou business Innovation (assurance classique vers en ligne, livraison par drone) éligible projet pilote car pas de passif. •Evolution du Legacy(existant ERP, Code ou Infra) : baby stepou les Dev et Opsse rejoignent vers le continuousdeliveryaprès avoir atteint un seuil de maturité minimal.
  38. 38. WOULD YOU LIKE TO KNOW MORE?
  39. 39. © 2012 Microsoft Corporation. Tousdroits réservés. Microsoft, Windows et les autresnomsde produitssontdes marques déposéesoudes marques commercialesde Microsoft aux États-Unis et/oudans d'autrespays. Les informationscontenuesdans cedocument sontfourniesuniquementà titreindicatif. Ellesreprésententl'opinionactuellede Microsoft Corporation surles points citésà la date de cetteprésentation. Microsoft s'adapteaux conditions fluctuantesdu marchéet cedocument ne doitpas êtreinterprétécommeun engagement de la part de Microsoft; de plus, Microsoft ne peutpas garantirla véracitéde touteinformation présentéeaprès la date de la présentation. MICROSOFT EXCLUT TOUTE GARANTIE, EXPRESSE, IMPLICITE OU STATUTAIRE, EN CE QUI CONCERNE CETTE PRÉSENTATION.

×