Etude de cas -DevOps

Michel PERFETTI

Radoine DOUHOU

Une entreprise tout à fait (dans la) normale

Il était une fois Contoso

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.

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 »

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 »

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.

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

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

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

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 ?

Changement d’organisation

Etape #1

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.

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.

Construction des environnements

Etape #2

“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

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

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

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

Continuous Deployment

Etape #3

Continuous delivery != Continuous deployment

Spec Dev Tests Deploy

Spec Dev Tests Deploy

Continuous delivery

Tâche manuelle

Continuous deployment

Tâche automatique

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

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

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

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)

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,…)

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?

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

Tests de charge

Visual Studio Web Load Tests + VSO

Web TestLoad Test

Application Insight

Site Web

Rapports

SQL Azure Monitor

Monitoring

Etape 4

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

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

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.

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

Ca a l’air simple mais…

Conclusion

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

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”

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.

WOULD YOU LIKE TO

KNOW MORE?

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