Dev opsday case study

39
Etude de cas - DevOps Michel PERFETTI Radoine DOUHOU

Transcript of Dev opsday case study

Page 1: Dev opsday   case study

Etude de cas -DevOps

Michel PERFETTI

Radoine DOUHOU

Page 2: Dev opsday   case study

Une entreprise tout à fait (dans la) normale

Il était une fois Contoso

Page 3: Dev opsday   case study

Le contexte

• L’offre :

▪ Vente de produits généralistes.

• Le marché :

▪ Hyperconcurrentiel et arrivée de gros acteurs étrangers sur un

marché mature.

• Mode de distribution :

▪ Multicanal: réseau d’agences et site eCommerce.

• Objectif :

▪ Développer de nouvelles offres innovantes pour conforter sa

place sur le marché ainsi que ses marges.

• Desired State Configuration.

Page 4: Dev opsday   case study

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-Prod avec

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 »

Page 5: Dev opsday   case study

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-Prod et Prod.

Ops

Métier Développement

Scrum « but »

Métier Développement

Scrum « but »

Métier Développement

Scrum « but »

Page 6: Dev opsday   case study

Incentives des équipes

Métier Développement Ops

• Succès des features

mises en places.

• Rapidité de mise sur le

marché

• Qualité de code (nb de

defects sur le code

produit).

• Respects des délais

fournis par le « métier ».

• Disponibilité et stabilité

de l’application (infra +

code).

• Délai de résolution des

incidents.

Page 7: Dev opsday   case study

Points de souffrance: Métiers & Dev

• Manque de visibilité sur les livraisons.

• Tests difficiles.

• Inertie des équipes DSI dans l’implémentation de nouvelles offres.

• Difficiles calculs de ROI car manque de business KPI’s fiables.

• Tentatives d’intégration d’appli SaaS laborieuse par manque de communication entre fournisseur et DSI.

Métier Dev

• Validation des fonctionnalités

• Besoins trop complexes.

• Une pression toujours plus forte du business face au Time To Market

Dev Métier

Page 8: Dev opsday   case study

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

Page 9: Dev opsday   case study

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

Page 10: Dev opsday   case study

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 ?

Page 11: Dev opsday   case study

Changement d’organisation

Etape #1

Page 12: Dev opsday   case study

Métier

Scrum

Changement d’organisation

Améliorer la collaboration Dev & Ops

DevOps

Dev Ops

• Dev :

▪ Application plus robuste : traces,

cas d’erreurs techniques

▪ participation des Ops au Design.

• 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.

Page 13: Dev opsday   case study

Effets visé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.

Page 14: Dev opsday   case study

Construction des environnements

Etape #2

Page 15: Dev opsday   case study

“Enable the reconstruction of the business from nothing but a

source code repository, an application data backup, and bare metal

resources”

Jesse Robins

Capacité à automatiser la construction et le maintien d’environnement technique

en les codant, réduisant ainsi les délais de mise à disposition aux équipes.

Couts

Déla

is

Managem

ent

+

-

Scala

bilité

Ressourc

es

-

+

Construction des environnements

Démarche Infrastructure As a Code

Page 16: Dev opsday   case study

Construction des environnements

Le 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, reprovisionner les environnements de Stress & Load Test

lorsqu’il n’est pas utilisé.

Page 17: Dev opsday   case study

Construction des environnements

Azure & DSC: better together

• Azure:

▪ Provisioning de VM.

▪ Scalabilité, Elasticité, Switch On/Off, Pay as

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é.

Page 18: Dev opsday   case study

Construction des environnements

Les apports pour notre projet

1

4

Les Dev ont leur environnement de Dev Jour J de leur arrivée.

Un environnement de Load Test disponibleet utilisable pour faire du TDD.

2

3 Une collaboration entre les Dev et Ops pourcoder une configuration iso-prod et réutilisable.

DevOps

Time To Market améliorée

Qualité améliorée

Page 19: Dev opsday   case study

Continuous Deployment

Etape #3

Page 20: Dev opsday   case study

Continuous delivery != Continuous deployment

Spec Dev Tests Deploy

Spec Dev Tests Deploy

Continuous delivery

Tâche manuelle

Continuous deployment

Tâche automatique

Page 21: Dev opsday   case study

Objectifs: livrer de la valeur “business” en continue

• Engranger du feedback

• Eviter l’effet tunnel

• Réduire les effets de bords

• Réduire l’écart entre la spécification et la livraison

• Livrer moins de choses, mais livrer plus souvent

Plus une chose est difficile, plus il faut la refaire pour la rendre simple

Page 22: Dev opsday   case study

Les Outils

Besoin User Story Tâche Code Build Tests Déploiement

Team Foundation Server / Visual Studio Online Release Management

On vise:

• La continuité dans les outils

• La traçabilité les changements

Page 23: Dev opsday   case study

Build

• Objectif :

▪ Est-ce que logiciel compile?

▪ Est-ce que les tests sont bons?

▪ Comment évolue la qualité du code?

• Gain :

▪ Maitrise de la génération des applications

▪ Contrôle qualité au plus près des développeurs

▪ Identification (et résolution) des problèmes au plus tôt

▪ Feedback rapide (en minutes)

▪ Quality gates

Page 24: Dev opsday   case study

Tests d’intégration

• Objectif :

▪ Passer le 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 :

▪ Tout le monde se concentre sur le développement de nouvelles

fonctionnalités

▪ La validation est en partie réalisée par des tests automatisés

▪ Gestion des régressions (un bug un test une correction)

Page 25: Dev opsday   case study

Déploiments automatisés

• Objectif :

▪ Identifier le pipeline de déploiement et les responsabilités

▪ Etre sûr que le logiciel est toujours déployable

▪ Déployer par petits incréments pour é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,…)

Page 26: Dev opsday   case study

Tests de charge

Le besoin pour notre projet

Spec Dev TestsLoad 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?

Page 27: Dev opsday   case study

Tests de charge

Visual Studio Web Load Tests + VSO

1Définition et implémentation des scénarii de tests

Exécution des tests sur Azure via Visual Studio Online2

3 Analyse des indicateurs de performance temps réel et génération de rapport à posteriori.

4 Identification des « bottlenecks » et optimisation

Page 28: Dev opsday   case study

Tests de charge

Visual Studio Web Load Tests + VSO

Web TestLoad Test

Application Insight

Site Web

Rapports

SQL Azure Monitor

Page 29: Dev opsday   case study

Monitoring

Etape 4

Page 30: Dev opsday   case study

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?”

Page 31: Dev opsday   case study

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

• Nouvelles possibilités:

▪ Canary

▪ Tests A/B

▪ Feature switch

▪ Hypothesis Driven Development

Page 32: Dev opsday   case study

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étriques métiers ajoutées par les dev :

▪ Produits les plus consultés.

▪ Taux de transformation.

Page 33: Dev opsday   case study

Performance et disponibilité

Solution Microsoft

Disponibilité

Servers forwarding data through SCOMWindows &

Linux Server

Cloud Service

Monitoring

Azure

Diagnostics

On Prem

IaaS

PaaS

Performance et

usage : New Relic

Page 34: Dev opsday   case study

Ca a l’air simple mais…

Conclusion

Page 35: Dev opsday   case study

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 dev et 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

Page 36: Dev opsday   case study

DevOps: éviter les 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”

Page 37: Dev opsday   case study

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

step ou les Dev et Ops se rejoignent vers le continuous

delivery après avoir atteint un seuil de maturité minimal.

Page 38: Dev opsday   case study

WOULD YOU LIKE TO

KNOW MORE?

Page 39: Dev opsday   case study

© 2012 Microsoft Corporation. Tous droits réservés. Microsoft, Windows et les autres noms de produits sont des marques déposées ou des marques commerciales de Microsoft aux États-Unis et/ou dans d'autres pays.

Les informations contenues dans ce document sont fournies uniquement à titre indicatif. Elles représentent l'opinion actuelle de Microsoft Corporation sur les points cités à la date de cette présentation. Microsoft s'adapte aux conditions fluctuantes du marché et ce document ne doit

pas être interprété comme un engagement de la part de Microsoft ; de plus, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de la présentation. MICROSOFT EXCLUT TOUTE GARANTIE, EXPRESSE, IMPLICITE OU STATUTAIRE, EN CE QUI

CONCERNE CETTE PRÉSENTATION.