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

1. Etude de cas - DevOps
Michel PERFETTI
Radoine DOUHOU

2. Une entreprise tout à fait (dans la) normale
Il était une fois Contoso

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. 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. 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. 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. 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. 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. 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. 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. Changement d’organisation
Etape#1

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. 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. Construction des environnements
Etape#2

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. 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. 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. 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. Continuous Deployment
Etape#3

20. Continuous delivery != Continuous deployment
Spec
Dev
Tests
Deploy
Spec
Dev
Tests
Deploy
Continuous delivery
Tâchemanuelle
Continuous deployment
Tâcheautomatique

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. 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. 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. 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. 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. 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. 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. Tests de chargeVisual Studio Web Load Tests + VSO
Web Test
Load Test
Application Insight
Site Web
Rapports
SQL Azure Monitor

29. Monitoring
Etape4

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. 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. 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. 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. Ca a l’air simple mais…
Conclusion

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. 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. 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. WOULD YOU LIKE TO KNOW MORE?

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.