"Continuous Delivery" et "DevOps" font partis des buzz word du moment dans l'IT.
Si vous n'êtes pas encore entrés dans ces démarches, ce n'est qu'une question de temps ! Préparez-vous à voir bientôt débarquer votre chef sur le bench avec le bouquin "Découvrir DevOps" sous le bras.
Mais pour les développeurs, ça change quoi le DevOps ? A travers cette conférence, je vais vous faire part des mes différents retours d'expérience sur ces changements autour des pratiques, organisations et outillages.
4. 32% des projets sont réussis
84% des projets dépassent le délai
64% des fonctionnalités développées ne sont pas
utilisées
Source : Chaos report 2009
Les projets cycles en V
25. 29% des entreprises ont adopté une
démarche DevOps
17% sont en phase de réflexion ou
d’expérimentation
19% utilisent la démarche DevOps pour
toutes leurs applications
Le DevOps en France
Etude IDC – Octobre 2016
30. 50 Millions de commandes en base
15 Millions de requêtes / jour
31. Des croyances
• Les équipes sont pluridisciplinaires
• D’entreprise : Tendre vers le DevOps, les équipes
sont autonomes dans la mise en œuvre
• Personnelles : team member multi-compétents
34. Exemple de code cucumber
Scénario: LT103-03-01-Recherche de solution multi-GO avec la date de départ sans tarif à condition d'aller-retour
Soit une recherche de solutions train aller-retour sur un trajet multi GO
Quand j'appelle le service de recherche de solutions tarifaires pour l'aller
Alors des solutions sont remontées
Et des solutions régionales "Pays de Loire" sont présentes
Alors(~'^des solutions (nationales|régionales) (?:"([^"]*)" ?|) sont présentes$'){
String go, String region ->
if (region == null) {
assert false, "Il faut indiquer une région"
}
// Récupération de l'OD à partir de son nom fonctionnel
GOsData gOsData = GOsData.getGOsData(go)
searchSolutionsAssertor.assertProposalsContainGo(gOsData.connector)
}
Remettre DevOps dans le contexte d’agilité
Grand principes
REX dans mes équipes
L'opéra de Sydney
1963 1973 (10 ans de retard)7 millions $ 102 millions $ (+1457%)
Cycle en V, interprétation
Constat après 30 ans de projets IT
Fervant défenseur du software craftmanship
Mon leitmotiv : que tout le monde travaille ensemble en partageant un objectif commun
Scrum master Voyages-sncf
Agilité à l’échelle de l’entreprise depuis 2012 (Chaîne Youtube VSC)
DevOps objectif d'entreprise depuis plus d'1 an
Co-fondateur cabinet de conseil
Pb en entreprise => manque de communication
#Agilité #Innovation #Management3.0 #Design #DevOps #Facilitation
Honda leader ➔ Yamaha menace Honda ➔ Honda : 30 nouveaux modèles de moto en 6 mois
Imprimante portable Epson Brother en -2ans ➔ 4 ans avant
Résultat : la performance dév. nouveaux produits complexes = équipes de petites tailles et auto-organisés, avec des objectifs, et non des tâches.
Conclusion : les équipes ont besoin d'autonomie pour atteindre l'excellence.
Equipes autonomes et pluri-disciplinaires pour éviter dépendances externes et goulot d’étranglement
Agilité rapprochement métier / dév
Dev & Ops : des objectifs orthogonaux
- Dev (développement) : évolution des systèmes
- Ops (exploitation) : garants stabilité et disponibilité des systèmes
DevOps rapprochement dév / ops
17 spécialistes dont
Ken Schwaber et Jeff Sutherland (SCRUM),
Martin Fowler (Design Pattern),
Kent Beck (Junit)
Lecture 16 ans après avec l’œil DevOps
Interaction dev et ops plutôt que ticket JIRA
Une usine plutôt que des procédures de livraison et d'installation
Collaboration avec les Ops plutôt qu’une négociation via DAT en début de projet
Scalling à la demande
Modification d’architecture
Coopération : Construire et MCO en commun
Livraison : Rapidité du TTM avec fiabilité et stabilité du produit
Elaboration : les PF ne doivent pas être un frein à l’innovation et l’innovation de doit pas mettre en péril les PF
- « Idéalement le client voulait mettre en prod … hier »
- Mise en production annuelle Euronet
- Concurrence mondiale et plus locale
- Être réactif et se différencier (TTM court, expérimentation)
- Utilisateurs cross fuseaux horaires ➔ pas de créneau sans downtime pour les installations
- Usine logicielle performante pour livrer rapidement et être réactif
Livrer rapidement mais sans faire de régression et s’assurer du bon fonctionnement (fonctionnel et technique)
Environnement similaire du dév à la prod, conf de prod jusqu’aux env de dév
Avoir connaissance de l’environnement de production (architecture technique, configuration)
infrastructure as a service :
Les dév ne sont plus ralentis par la mise à disposition d’environnement
Les dev ne ralentissent plus les Ops avec des demandes d’actions sans valeur ajoutée
infrastructure as Code (docker) et autres solutions
Etre sensibilisé aux logs : informations, niveau, process derrière chaque niveau exemple XLLog et déclenchement PAD
Le développeur est à mi-chemin entre la connaissance métier et la connaissance technique.
Définir et produire des indicateurs pertinents (impact sur le code)
Feature toggle : pas cher si prévu de suite => être sensibiliser et sensibiliser lors des sprints plannings
Dark launch OU Canary releases : concevoir son application tel quelle
Loi de Murphy : “Tout ce qui est susceptible de mal tourner tournera nécessairement mal”
Se préoccuper de la résilience (ex l’envoi mail) Cf conf de Quentin Cloudbees
Faire référence à la conf précédente Netflix OSS
Selon IDC, pourcentage va passer à 50% en 2017
http://www.channelnews.fr/devops-a-vent-poupe-lhexagone-70853
Démarche de transformation :
Optimiser ce qui nous prend du temps (Build, Test, Release)
Prendre le feedback des Ops (Deploy et Operate)
Amélioration continue sur tout le cycle
REX de mon équipe
Portail de distribution offre SNCF
Plusieurs clients sur plateforme commune (VSC, BLS, Train line, ...)
Plusieurs partenaires (central SNCF, IdCAB, ...)
Sprint de 3 semaines, Dév à Nantes / Ops à Lille
Usine logicielle basée sur Jenkins, Rundeck, Puppet
TTM 9 semaines sortie de dév
Toutes les commandes de la SNCF
Requêtes : devis, vente et après-vente => cible à 75M
Pouvoir tester de manière continue
Démarche BDD pour documenter nécessite de connaître les cas d’usage
Patrimoine de +2500 scénarios
Test en continu et priorisation
C’est du code
Anecdote un testeur un développeur avec expertise test
Développement de Zucchini à l’initiative par Pierre
Test de performance nécessite de connaître les cas d’usage les plus utilisés et les volumétries
Test en continu Pipeline Jenkins 2
Développement outils envoi rapport par mail
C’est du code
Pouvoir builder et releaser de manière continue
Pas micro-service mais muti-composants
1 GIT par composant
Truck factor sur l’intégrateur rôle tournant sur chaque équipe
Intégrateur développeur mais expertise intégration
Résultat :
- Difficulté pour release globale à partir de l’usine création outil maison
- Contribution à l’usine logicielle pour spécificités (ex Mongo, Kafka)
C’est du code
Citer aussi pipeline Jenkins 2
Pouvoir déployer de manière continue
Accompagner les mises en production : participer aux réunions en amont, connaître les process de MEP
Suivre les dashboard : être attentif et réactif
Bon là c’est pas du code
Opérer de manière continue
Fin de l’équipe supervision
Construction des boards et centralisation des logs
Tir de charge
Création communauté, 2 mois pour monter en compétences
Création des boards grafana / Montée en compétence sur les différents frameworks (Spark pour map reduce)
Contribution à la communauté
Exemple de rapports Grafana
C’est du code
Travail pour rationnaliser les scénarios Gatling
Difficulté pour montée en compétence sur l’analyse de métriques JVM
Croyance team member multi compétent tombe à l’eau
A l’instar de Netflix en prod
Mise en œuvre des chaos monkeys => communauté
Plan Reprise Activité sur 2 sites
Ex : intervention volontaire en prod
Après 2 ans
Toujours dispo même quand les partenaires sont down
Peu d’anomalies découvertes (surtouts fonctionnelles) rapidité pour patcher
Livre bien tous les 2 sprints
Mais c’est quand même du code
Scalabilité (VSC ODV 30 billets/s, 1 TGV 20s) on y est pas
Infra as code Docker ?
Démarche lean commit to prod
Gestion des perturbation dans les équipes gérer le build et le run
Team member multi-compétents perte expertise, montée en compétence nouveaux
NoOps est-ce qu’on veut aller vers cela ?
CONCLUSION : perpétuelle remise en question
Anecdote recrutement la philosophie n’est pas là
Anecdote matthieu REDIS feedback de la prod, la philosophie est là
Devise FCNA : « Celui qui cesse vouloir devenir meilleur cesse déjà d’être bon »