http://joind.in/talk/view/11245 Dans notre économie numérique, ce n’est pas les gros qui mangent les petits, c’est les rapides qui mangent les lents. Les méthodes de gestion de projets informatiques traditionnelles ont mené à des échecs spectaculaires en termes de délais et de gestion de risque. En parallèle, des leaders du web tels qu’Amazon, Netflix ou Google ont atteint une vélocité incroyable grâce à une implémentation audacieuse des principes d’agilité. Parmi ces différents mouvements agiles, DevOps rassemble des experts du développement et de l’opérationnel sur la manière dont doit être implémentée l’agilité, de la conception technique jusqu’à la mise en production, pour atteindre une vélocité maximale. Dans cette conférence, je partagerai l’expérience de Theodo sur plusieurs projets de grande envergure (jusqu’à 15 développeurs). Je présenterai ce que DevOps signifie pour nous et comment il nous aide à livrer nos projets de manière plus rapide et plus fiable. Nous passerons en revue les challenges auxquels nous avons été confrontée, tant d’un point de vue management, technique ou culturel et présenterons les solutions que nous avons trouvées, basées sur des technologies puissantes : Symfony2, OpenStack, Puppet, Vagrant, Capifony, Jenkins, Behat et d’autres…

1. Le Miracle DevOps
Comment accélérer le passage en production
1

2. matts2cant@gmail.com
@matts2cant
2

3. • Le besoin de rapidité
• Le miracle DevOps : Les faits
• Mettre en place DevOps, pas à pas
3

4. Le business
nécessite
la rapidité
4

5. Le cycle en V est long et risqué …
?
5

6. … bien plus long et risqué que prévu
• Une étude de 2 professeurs d’Oxford sur 1471
projets IT d’envergure montre :
• 1 projet sur 6 coute en moyenne 3x plus que prévu
• Exemple :
• Faillite de FoxMeyer Drugs après être passé brutalement à
SAP
Oxford study: http://eureka.bodleian.ox.ac.uk/897/1/WP_2011_08_15.pdf
Fox-Meyer bankruptcy: http://fr.slideshare.net/jmramireza/the-foxmeyer-drugs-bankruptcy-was-it-a-failure-of-erp-2332065 6

7. Nos cerveaux estiment très mal la
probabilité des évènements rares
7

8. -Machiavel
« Divide et impera! »
(Diviser pour régner)
8

9. Le développement agile :
Une série de « fausses » iterations
9

10. Car les features s’entassent et ne
passent pas en production
DEVS OPS
10

11. Scrum n’est que le début
Jeff SutherlandKen Schwaber
11

12. • Le besoin de rapidité
• Le miracle DevOps : Les faits
• Mettre en place DevOps, pas à pas
12

13. DevOps
Résoudre le problème du silo
13

14. Faire travailler en
équipe
les Devs en les Ops vers des
objectifs communs
14

15. La trinité DevOps
15

16. L’efficacité du DevOps est largement
documentée sur le web
• Rapport de productivité sur 620 ingénieur
(RebelLabs, 2013)
• Rapport « State of DevOps » sur 4000 ops et
devs (PuppetLabs, 2013)
• And all the testimonials from web leaders like
Amazon, Netflix, Etsy, Flickr, etc. (at Velocity
Conference, DevopsDays, etc.)
State of DevOps by puppet labs: https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf
RebelLabs productivity report: http://pages.zeroturnaround.com/RebelLabs-AllReportLanders_DevopsProductivityReport.html 16

17. Les DevOps délivrent
30% plus fréquemment
• 7% des non-DevOps
déploient sur demande contre
27% pour les devOps
• 35% des non-DevOps
déploient moins d’une fois par
mois contre 13% pour les
DevOps
Temps moyen entre
déploiements
0
25
50
75
100
Non DevOps DevOps > 1 an
> 180 jours
30 - 180 jours
7 - 30 jours
1 - 7 jours
Sur demande
17

18. Les DevOps délivrent
8000x plus vite !
• 7% des non-DevOps
déploient en moins d’une
heure contre 23% pour les
devOps
• 25% des non-DevOps
nécessitent plus d’un mois a
déployer !
Temps moyen d’un
déploiement
0
25
50
75
100
Non DevOps DevOps > 1 an
> 6 mois
1 - 6 mois
7 - 30 jours
1 - 7 jours
< 1 jour
< 1 heure
18

19. Les DevOps ont 50%
d’erreurs en moins
• Les équipes qui échouent
plus d’un déploiement sur dix
passent de 40% à 23% avec
DevOps
Temps moyen entre
déploiements
0
25
50
75
100
Non DevOps DevOps > 1 an
> 50%
30 - 50%
10 - 30%
5 -10%
< 5%
19

20. Les DevOps ont 50%
d’erreurs en moins
• 47% des équipes DevOps
résolvent leurs erreurs de
déploiement en quelques
minutes seulement
Temps moyen de résolution
0
25
50
75
100
Non DevOps DevOps > 1 an
Plusieurs jours
Quelques heures
Moins d'une heure
Quelques minutes
20

21. Amazon déploie en moyenne
300 fois par heure
• Fondé en 1994, 75 Milliard $ en 2013
• Temps moyen entre les déploiements : 11.6s
• Nombre max de déploiements en une heure : 1079
• Nombre moyen de machines hôtes : 10000
http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf
http://en.wikipedia.org/wiki/Amazon.com 21

22. Chez Etsy, chaque ingénieur
déploie le jour de son arrivée
• Fondé en 2005, 1 Milliard $ de transactions en 2013
• 250+ contributeurs, chaque personne déploie
• 30+ déploiements par jour
• Chacun déploie le jour de son arrivée
http://codeascraft.com/2012/03/13/making-it-virtually-easy-to-deploy-on-day-one/
https://speakerdeck.com/astanway/bring-the-noise-continuously-deploying-under-a-hailstorm-of-metrics
http://gigaom.com/2013/08/23/meet-the-man-behind-new-yorks-other-billion-dollar-internet-company-this-one-makes-money/ 22

23. Le gouvernement Anglais a adopté
DevOps de manière de manière radicale en
moins d’un an
• gov.uk est le site de tous les départements et agences publiques
• Version alpha en 2011 avec 4 devs
• Site live en octobre 2012
• 15-20 déploiement par jour
• Principal argument commercial : plus rapide que tous les autres prestataires
http://vimeo.com/album/2384821/video/66622266
https://github.com/philandstuff/devopsdaysparis#kushal-pisavadia-kushalp-how-we-ship-software-at-govuk
https://www.gov.uk/service-manual 23

24. • Le besoin de rapidité
• Le miracle DevOps : Les faits
• Mettre en place DevOps, pas à pas
24

25. Créer un esprit d’équipe
entre les devs et les ops
• 1. Eduquer les devs sur les contraintes opérationnelles
• 2. Inciter les ops a déléguer du pouvoir aux devs
• 3. Mélanger les équipes de devs et d’ops
25

26. Le background « classique »
d’un développeur
• A appris Java en école/a
l’université
• Utilise Windows (Jeux !)
• A installé Linux car il est
curieux
• A réalisé plusieurs sites
pour son école ou ses amis
• Déploie avec FileZilla
26

27. Etape 0 : Transformer le bébé dev en
dev respectable
• Environnement Unix
• Contrôle de version (Git)
• Workflow
• Méthodologie agile
• Tests unitaires et fonctionnels
27

28. Etape 1 : Lui donner un serveur
pour s’amuser
• Donner une instance micro a
tout le monde
• Libre de faire ce qu’on veut,
quand on veut dessus
• … tout en restant légal :)
28

29. Etape 2 : Lui faire installer un serveur
… au moins deux fois
• Beaucoup de devs juniors
n’ont jamais installé de
serveurs
• Deux fois : pour comprendre
l’intérêt du provisioning
automatique
29

30. Etape 3 : Le faire déployer … et
comprendre comment ça marche
• Script shell ✘
• Capistrano ✔
• Fabric ✔
• Ansible ✔
30

31. Etape 4 : Faire du monitoring une
étape évidente
• Le monitoring est devenu facile (NewRelic, AppDynamic, ELK)
• Facilite de debug (StackTraces, Requêtes SQL, Page performances, HealthCheck)
31

32. Etape 5 : Responsabiliser les devs sur
l’intégration continue
• Jenkins : Très flexible et complet
• Travis-CI : Très facile a mettre en place
• CodeShip : Déploiement continu
• GitLab-CI : Intégration avec GitLab
32

33. Etape 6 : Normaliser les
environnements avec Vagrant
• Limite les effets de bord (32/64 bits,
Configuration, OS, etc.)
• Différents providers (VirtualBox,
Openstack, EC2, Docker, etc.)
• vagrant package : share boxes
between devs
33

34. Etape 7 : utiliser Vagrant avec un
provisioning automatique
• Apprendre puppet et chef est une
étape douloureuse pour un dev …
mais moins que le provisioning
manuel
• Pour créer le script:
• Un Ops expérimenté crée un template
• Un Dev expérimenté challenge et simplifie
34

35. Etape 8 : Utiliser le cloud !
• Cloud privé : Openstack
• Cloud publique : Amazon EC2
35

36. Etape 9 : Rendre le backup facile
• Push to S3/Swift
• Ou des solutions comme Idera ServerBackup
36

37. Etape 10 : Créer une plateforme de
test de charge
• Créer un serveur facile d’accès (VNC) avec une grande
bande passante
• Les Ops expliquent aux Devs ce qu’est un bon test de
charge
• Tester les performances régulièrement avec Devs+Ops
37

38. Etape 11 : Inciter au
« pair-devopsing »
• Les devs ont un problème avec Puppet/Chef ?
• Les tests de charge montrent un problème de performances ?
• Les Ops voient des erreurs dans les logs ?
!
-> Pair devopsing
38

39. Etape 12 : Utiliser la management
visuel pour aligner les intérêts
Comment amener les devs a s’intéresser aux performances :
• L’inclure dans la definition du DONE
• Inclure des solutions de mesure de performances dans le
provisioning
• Afficher des graphes de performances
39

40. 40

41. Prochaines étapes :
• Velocity conferences
• http://lanyrd.com/2013/velocity/coverage/
• http://lanyrd.com/2012/velocity/coverage/
• “Top 11 things you need to know” - Gene Kim
• http://www.thinkhdi.com/~/media/HDICorp/Files/White-Papers/
whtppr-1112-devops-kim.pdf
• Blog Etsy
• http://codeascraft.com/
• Blog Netflix
• http://techblog.netflix.com/
41

42. DevOps
is hard
42

43. Questions ?
matts2cant@gmail.com
@matts2cant
43