Le document explique les concepts de déploiement continu, d'intégration continue et de livraison continue en fournissant des statistiques sur les déploiements pour des entreprises comme Facebook et Amazon. Il souligne l'importance de l'automatisation, des tests rigoureux, et des méthodes comme le feature flipping et le blue-green deployment pour minimiser les risques et améliorer la qualité du code. Enfin, il insiste sur le fait que l'objectif est d'accélérer le développement tout en maintenant des standards de qualité, et d'apprendre des erreurs pour perfectionner le processus.

1. Déployer en continu
Benoît Lafontaine
OCTO Technology

2. Quelques chiffres
Facebook : > 2 déploiements par jour
Flick : > 10 déploiements par jour
Etsy : > 25 déploiements par jour
Amazon :
(1 déploiement toutes les 10 secondes sur 10000 machines)

3. Définitions

4. Continuous integration
A intervalle régulier, voire à chaque commit,
le code est :
! Compilé
! Testé
! Assemblé
! Déployé sur un environnement d’intégration

5. Continuous delivery
A intervalle régulier, voire à chaque commit,
le code est :
! Compilé
! Testé
! Assemblé
! Déployé sur un environnement d’intégration
! Livré à l’équipe suivante (QA, MEP…)

6. Continuous deployment
A intervalle régulier, voire à chaque commit,
le code est :
! Compilé
! Testé
! Assemblé
! Déployé sur un environnement d’intégration
! Testé sur cet environnement (automatiquement)
! Déployé en production !!!

7. POURQUOI,
POURQUOI,
POURQUOI ?

9. Feedback

10. C’est pas déjà ce qu’on fait
avec les méthodes Agiles ?

11. Code produit
Temps

12. Code produit
Temps
Code livré

13. Code produit
Temps
Dev
Code livré

14. Code produit
Temps
Dev ???
Code livré

15. Code produit
Temps
Code livré

16. Code produit
Temps
Code livré
Dev FEEDBACKS

17. Pourquoi on le fait pas ?

18. La peur

19. Perte de temps

21. Qualité ?

22. Code produit
Temps
Code livré

23. Code produit
Temps
Code livré
Beaucoup de changements
=
Beaucoup de risques

24. Code produit
Temps
Code livré

25. Code produit
Temps
Code livré
Peu de changements
=
Peu de risques

26. John Allspaw, Etsy
http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change

27. Réduire la taille des déploiements…
Minimise les risques
Réduit le « Time To Repair » (TTR)
Réduit le temps d’indisponibilité

28. Déployer en continu c’est :
Construire un meilleur produit grâce à plus de feedbacks
Gagner du temps en huilant son processus de déploiement
Améliorer la qualité en limitant les risques d’une livraison

29. COMMENT,
COMMENT,
COMMENT ?

30. Automatiser !

32. DEVOPS

33. Déployer en 1 clic

34. QUESTIONS,
QUESTIONS,
QUESTIONS !!!

35. Question#1 : 0 commits ?

36. Vas-y commit…

37. Garantir la qualité
Intégration continue
TESTS ! (automatisés bien sûr)
! TDD
! Tests d’IHM
! Tests de performance
! …

38. Garantir la qualité

39. Question #2 : En construction ?

40. dissocier le déploiement de code
de l'activation de fonctionnalité

41. Feature flipping

42. Flipping code

44. Question #3 : Downtime ?

45. Blue green deployment

46. Question #4 : Migration de schémas de BDD ?

47. Migration de schéma : solution
Séparer les scripts de migration en
! Scripts d’expansion (ADD)
! Scripts de contraction (DROP)
! ALTER

48. Cas d’exemple

49. Exemple : Modification du champs adresse
Version N
Ecriture
Lecture

50. Exemple : Modification du champs adresse
Version N
Ecriture
Lecture

51. Exemple : Modification du champs adresse
Version N+1
Ecriture
Lecture

52. Exemple : Modification du champs adresse
Version N+2
Lecture
Ecriture

53. Exemple : Modification du champs adresse
Version N+2
Lecture
Ecriture

54. Exemple : Modification du champs adresse
Version N+2
Lecture
Ecriture

55. Question #5 : Est-ce qu’on active ?

56. Canary Release

57. Question #6 : Et si ça explose ?

58. Rappel : réduire la taille des
déploiements réduit les risques

59. Mesurer et superviser

60. Arrêt d’urgence

61. Toute anomalie en production provoque
! une alerte visible par tous
! L’arrêt d’urgence, on ne peut plus commiter
« L’objectif est d’aller aussi vite que possible
pour produire du code de qualité, pas plus
vite »

62. N’accepter l’erreur qu’une seule fois
1 erreur => 1 action

63. Question #7 : Rollback ?

64. “we don’t roll back,
we fix the code”
John Allspaw - Etsy

65. Take away : pourquoi déployer en continu
Gagner en temps
Gagner en qualité
Plus de feedbacks

66. Take away : comment déployer en continu
! Automatisez vos déploiements
! Dissociez la livraison de code et l’activation de
fonctionnalité avec du feature flipping
! Sécurisez les déploiements avec les tests et les
patterns de déploiements (blue-green, canary
release)
! Profitez des erreurs pour améliorer votre processus

67. Merci
Benoît Lafontaine
bla@octo.com
@joel1di1
https://github.com/joel1di1