Ce diaporama a bien été signalé.

Au secours, mon chef m'a demandé de passer au DevOps

10

Partager

Chargement dans…3
×
1 sur 59
1 sur 59

Au secours, mon chef m'a demandé de passer au DevOps

10

Partager

Télécharger pour lire hors ligne

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

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

Plus De Contenu Connexe

Livres associés

Gratuit avec un essai de 14 jours de Scribd

Tout voir

Au secours, mon chef m'a demandé de passer au DevOps

  1. 1. Au secours, mon chef m'a demandé de passer au DevOps !
  2. 2. 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
  3. 3. Antony GUILLOTEAU @aguilloteau
  4. 4. Takeuchi et Nonaka (1982)
  5. 5. TODO
  6. 6. Design Code Test Deploy Design Code Test DeployCode Test Code Test Code Test Waterfall Agile
  7. 7. DevOps Design Design Code Test Deploy Waterfall Design Code Test DeployCode Test Code Test Code Test Agile
  8. 8. Les 4 valeurs du Manifeste Agile (2001)
  9. 9. #1 Les individus et leurs interactions plus que les processus et les outils
  10. 10. #2 Des logiciels opérationnels plus qu’une documentation exhaustive
  11. 11. #3 La collaboration avec les clients plus que la négociation contractuelle
  12. 12. #4 L’adaptation au changement plus que le suivi d’un plan
  13. 13. Les objectifs du DevOps #1 Améliorer la coopération entre Dev et Ops #2 Améliorer la livraison du produit #3 Fluidifier l’élaboration du produit
  14. 14. Livrer rapidement
  15. 15. Développer avec la cible
  16. 16. TODO Monitorer pour prévenir
  17. 17. Un produit stable
  18. 18. Être résilient
  19. 19. 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
  20. 20. https://www.linkedin.com/pulse/dynamics-devops-adoption-dr-pallab-saha Plan Code Build Test Release Deploy Operate Agile Development Continuous Integration Continuous Delivery Continuous Operations Continous Deployment
  21. 21. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  22. 22. PORTAI L VENTE PartenairePartenaire Partenaire ClientClient Client
  23. 23. 3 équipes SCRUM Usine logicielle d’entreprise Livraison tous les 2 sprints
  24. 24. 50 Millions de commandes en base 15 Millions de requêtes / jour
  25. 25. 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
  26. 26. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  27. 27. Automatisation des tests fonctionnels Plan Code Build Test Release Deploy Operate
  28. 28. 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) }
  29. 29. Zucchini pour suivre les exécutions des scénarios Cucumber
  30. 30. Automatisation des tests de performance Plan Code Build Test Release Deploy Operate
  31. 31. Exemple de scénario Gatling Object SearchScenario { private val category = csv("category.csv").random private val keyword = csv("keyword.csv").random val scn : ScenarioBuilder = scenario("Search") .exec().feed(keyword).randomSwitch( 80d -> exec(http("Search by keyword").get("/search?q=${keyword}").check(status.is(200))), 20d -> exec(http("Search by category").get("/search?q=${category}").check(status.is(200))) ) } class GatlingSimulation extends Simulation { val httpConf = http.baseURL("http://localhost:8080/").userAgentHeader("Gatling").disableCaching setUp( SearchScenario.scn.inject(rampUsersPerSec(1) to(20) during(5 minutes)) ).protocols(httpConf) }
  32. 32. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  33. 33. Architecture multi-composant ComposantComposant Composant Plan Code Build Test Release Deploy Operate
  34. 34. Extrait code orchestrateur de release public void createReleaseBranch(Delivery delivery, Execution execution) throws Exception { for (DeliveredComponent component : delivery.getComponents()) { FullGitRepo gitRepo = new FullGitRepo(configuration.getWorkspace(), component.getComponent()); execution.executeOnce(component.getComponent().getName(), "create release branch", () -> { gitRepo.createBranch(computeReleaseBranchName(delivery.getReleaseVersion()), delivery.getBranch()); if (!delivery.isDryRun()) { gitRepo.push(); } }); execution.executeOnce(component.getComponent().getName(), "update pom for next snapshot", () -> { gitRepo.switchToBranch(delivery.getBranch()); gitRepo.hardReset(); File pomFile = gitRepo.findFile("pom.xml"); Properties mavenProps = new Properties(); mavenProps.setProperty("developmentVersion", delivery.getNextSnapshotVersion().toString()); dependenciesService.updateDependenciesInPom(delivery, component, pomFile, delivery.getNextSnapshotVersion()); gitRepo.add("."); gitRepo.commit("[ReleaseTool] update module and dependencies versions in pom.xml to " + delivery.getNextSnapshotVersion()); if (!delivery.isDryRun()) { gitRepo.push(); } }); } }
  35. 35. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  36. 36. Suivi des mises en production Plan Code Build Test Release Deploy Operate
  37. 37. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  38. 38. Supervision et centralisation des logs Plan Code Build Test Release Deploy Operate
  39. 39. Exemple de requête Spark val ref_rdd = sc.textFile("/user/logflmp1/2017-02-01/*/log_haproxy*.log") case class HaProxyLine(frontend: String, backend: String, instance : String, timestamp8601: String, errorCode: String, elapsedTimeMs: String) val haProxyLines = ref_rdd.map(s => s.split(" ")).map( s => HaProxyLine( s(3).substring(3).replace("~", ""), s(4).substring(0, s(4).lastIndexOf("/")), s(4).substring(s(4).lastIndexOf("/") + 1), s(2), s(6), s(7)) ).toDF().registerTempTable("haproxylines") val columnsGlobalStats = s"frontEnd, backEnd, instance, splitToGroup(timestamp8601), splitToTZ(timestamp8601)" val columnsErrors = s"$columnsGlobalStats, errorCode" val dataFrame = sqlContext.sql( "select frontEnd, backEnd, instance, splitToGroup(timestamp8601), splitToTZ(timestamp8601), count(*), avg(elapsedTimeMs) " + "from haproxylines group by $columnsGlobalStats") val dataFrameError = sqlContext.sql( "select $columnsErrors, count(*), avg(elapsedTimeMs) " + "from haproxylines where errorCode >= 400 group by $columnsErrors") val rdd = dataFrame.rdd
  40. 40. Plan Code Build Test Release Deploy Operate
  41. 41. Aujourd’hui Une prise de recul
  42. 42. Taux de dispo de 99,5 % 5 bugs bloquants découverts en production Livraison tous les 2 sprints
  43. 43. Les activités d’un développeur c’est
  44. 44. Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations DevOps
  45. 45. DevOps Agile Development Continuous Integration Continuous Delivery Continuous Deployment Continuous Operations
  46. 46. Le DevOps c’est du dév … Et avant tout une philosophie
  47. 47. https://goo.gl/forms/YCZbdwMNStBqGgZq2 Merci pour votre feedback

Remarques

  • 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 »
  • ×