deployer en continu, benoît lafontaine, usievent 2013

Déployer en continu

Benoît Lafontaine OCTO Technology

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)

Définitions

Continuous integration

A intervalle régulier, voire à chaque commit, le code est :

!   Compilé !   Testé !   Assemblé !   Déployé sur un environnement d’intégration

Continuous delivery


!   Compilé !   Testé !   Assemblé !   Déployé sur un environnement d’intégration

!  Livré à l’équipe suivante (QA, MEP…)

Continuous deployment


!   Compilé !   Testé !   Assemblé !   Déployé sur un environnement d’intégration !   Testé sur cet environnement (automatiquement) !  Déployé en production !!!

POURQUOI, POURQUOI, POURQUOI ?

Feedback

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

Code produit

Temps

Code produit

Temps

Code livré

Code produit

Temps

Dev

Code livré

Code produit

Temps

Dev ???

Code livré

Code produit

Temps

Code livré

Code produit

Temps

Code livré

Dev FEEDBACKS

Pourquoi on le fait pas ?

La peur

Perte de temps

Qualité ?

Code produit

Temps

Code livré

Code produit

Temps

Code livré

Beaucoup de changements =

Beaucoup de risques

Code produit

Temps

Code livré

Code produit

Temps

Code livré

Peu de changements =

Peu de risques

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

Réduire la taille des déploiements…

Minimise les risques Réduit le « Time To Repair » (TTR) Réduit le temps d’indisponibilité

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

COMMENT, COMMENT, COMMENT ?

Automatiser !

DEVOPS

Déployer en 1 clic

QUESTIONS, QUESTIONS, QUESTIONS !!!

Question#1 : 0 commits ?

Vas-y commit…

Garantir la qualité

Intégration continue TESTS ! (automatisés bien sûr)

!   TDD !   Tests d’IHM !   Tests de performance !   …

Garantir la qualité

Question #2 : En construction ?

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

Feature flipping

Flipping code

Question #3 : Downtime ?

Blue green deployment

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

Migration de schéma : solution

Séparer les scripts de migration en

!   Scripts d’expansion (ADD)

!   Scripts de contraction (DROP)

!   ALTER

Cas d’exemple

Exemple : Modification du champs adresse

Version N E

critu

re Lecture


Version N

Ecr

iture

Lecture


Version N+1

Ecr

iture

Lecture


Version N+2

Lecture Ecr

iture

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

Canary Release

Question #6 : Et si ça explose ?

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

Mesurer et superviser

Arrêt d’urgence

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 »

N’accepter l’erreur qu’une seule fois

1 erreur => 1 action

Question #7 : Rollback ?

“we don’t roll back, we fix the code”

John Allspaw - Etsy

Take away : pourquoi déployer en continu

Gagner en temps Gagner en qualité Plus de feedbacks

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

Merci

Benoît Lafontaine

[email protected] @joel1di1

https://github.com/joel1di1