Continuous Delivery chez LesFurets -- Deep dive Dec 2015

Livrer chaque jour ce qui est prêt 
Continuous Delivery & Continuous Merge

@BeastieFurets#LesFuretsContinuous
1er site indépendant de comparaison d’assurance :
• Lancé en 2012
• 2,5M de devis par an
• 31% du marché de la comparaison de contrats auto

4

Application
• 6 produits :
• Java (tomcat) & GWT (client)
• 400k LOC & 40k tests unitaires
• 200 tests Selenium
• 22 Devs & Tech Leads, 2 Ops, 2 Managers

Rythme 2012 - Mensuel
12 releases
L’esprit :
planiﬁer / estimer / coder / tester /
liver de manière mensuelle
Sprints

L’ancienne organisation en SCRUM classique :
• Sprints d’un mois, Planiﬁcation au mois, Recette 1 semaine
• Build : 15 minutes
• 200 Seleniums : 1 heure
• Blocages : Build + Selenium + Recette
Rythme 2012 - Mensuel

Rythme 2013 - Mois + Sem
45 releases
L’esprit :
planiﬁer / estimer / coder / tester
liver de manière mensuelle
Sprints + Bonus
Déploiement chaque semaine (cherry-pick)

• Livraison mensuelle + cherry-pick chaque semaine en bonus
• Améliorations:
• Build : 3 minutes (contre 15 minutes)
• Blocages:
• Selenium + Recette
Rythme 2013 - Mois + Sem

Rythme 2014/15 - Quotidien
208 releases en 2014 (déjà 150 en 2015)
L’esprit :
livrer ce qui est prêt aujourd’hui
… tous les jours !
Marathon

• Livraison mensuelle + cherry-pick chaque semaine en bonus
• Améliorations:
• Selenium : 10 minutes + Zeno (regressions graphiques)
• Blocages:
• Temps de release (2-3h par 1 dev)
• Risque par release (15d / release en moyenne)
Rythme 2014/15 - Jour

0"
20"
40"
60"
80"
100"
120"
140"
160"
10" 20" 30" 40" 50" 60" 70" 80" 90" 100" 250" 500" 1000" 5000" 5000"
Histogramme"du"nombre"de"modiﬁca<on"des"releases"
Releases & Modifications
13
Par Release
>150 lignes
5 - 6 Tickets
2h de travail
Objectif:
100 lignes
10min

Objectif 2016 - Par feature
500+ releases en 2016 (déjà 150 en 2015)
L’esprit :
livrer ce qui est prêt aujourd’hui
… par fonctionnalité !
Marathon

Time To Market
• 2012 :
➡ Début dev à la MEP : Temps dev + 2 semaines
➡ Non satisfaisant pour le business
• 2014 :
➡ Début dev à la MEP : Temps dev + 2 jours
➡ Quand c’est prêt

Vue du métier : 2012
• Mindset “Itération” :
➡ Focalisé sur la date de livraison de l’ensemble
➡ Tendance naturelle à charger
• Mauvaises Surprises :
➡ Pas dans la release = Au min 1 itération d’attente
➡ Demande de livraisons séparées (pour voir l’impact !)

• Mindset “Quand c’est prêt” :
➡ Petit = vite
➡ Tendance naturelle à alléger
• Bonnes Surprises :
➡ Demande de livraisons séparées (pour voir l’impact !)
➡ MVP devient naturel pour décider des gros projets
➡ Pas dans la release = au min +1 jour
Vue du métier : 2014+

Livraison Continue – Jours / Heures

Manifeste agile
Principe #1
« Notre plus haute priorité est de satisfaire le client
en livrant rapidement et régulièrement
des fonctionnalités à grande valeur ajoutée. »
http://agilemanifesto.org/iso/fr/principles.html

Livrer tôt, livrer souvent
http://paulhammant.com/2013/03/13/facebook-tbd-take-2/

Continuous Delivery
1. Build rapide
2. Build robuste
3. Déploiements simples et automatisés
4. Monitoring de production et alertes
5. Analyse des causes racines

Git / Git Flow / Github Flow
Git: Un puissant modèle de branches
http://nvie.com/posts/a-successful-git-branching-model/
Master
Branch
Pull
Request
Github

Points clés : de la
conception à l’exploitation

Améliorer par la fin
5. Monitoring & Exploitation
4. Mise En Production
3. Release Création &Validation
2. Développement
1. Conception

Flux de fonctionnalités
• #1 Fonctionnalités conçues pour être indépendantes
• Livrable dès que c’est prêt
• Découplage des fonctionnalités
• Si dépendant alors attendre ou fusionner
• #2 Fast feedback
• Petites taches vites en production
• Retour chiffré rapide pour prise de décision : stop / cont.

Organisation
Prioritisation
Resource Allocation
Team Team Team
Strategic program initiatives
5%
RUN
35%
BAU /
QUAL
60% BUILD

Flow from Portfolio
29

Environnement Dev
• Chaque fonctionnalité sur une branche feature dédiée
• Code Production (master) + fonctionnalité uniquement
• Isolation sur le poste de chaque développeur (+ alias DNS)
• Environnements quasi iso Production
• Capacité de se focaliser sur ce développement

Intégration Continue
Feature Branching + Intégration Continue

Intégration Continue
L’intégration continue effectue à chaque commit :
• Compilation
• Tests automatisés
• Merge des features branches (Octopus)
➡ On fait du continuous merge avec l’Octopus

Continuous Merge Octopus
• Outil Open Source de merge en continu
• Développé en interne chez LesFurets.com :
➡ https://github.com/lesfurets/git-octopus
• Il existe une conférence dédiée par Arnaud Pﬂieger

Continuous Merge Octopus

Environnement Stage
• Quasi iso environnement de Production
• Regroupement de toutes les features en cours (Octopus)
• Effets de bord des features
• Seleniums sur le regroupement
• Suivi des logs plus facile

3. Release Création &
Validation

Création Release Branche
Création entièrement automatisée :
• Regroupement des features prêtes (Octopus)
• Déploiement sur Pre-Prod (quasi iso Prod)
• Validation sur Pre-Prod

Validation Release Branche
Validation à l’aide d’outils manuels et automatiques :
• Tests unites et d’intégration
• Code review
• Validation fonctionnelle (sur env Stage)
• Grid Selenium
• Non régression UI (Zeno)

Grid Selenium on LXC
• 200 Tests Selenium : 6 heures
• Grid Selenium classique : 1heure
• Grid Selenium RamFS : 10 minutes
• 1 Machine OVH, 128 Go RAM, 300 euros/mois
• Détails sur https://github.com/lesfurets/selenium-lxc

Zeno Pixel
• Outil Open Source de comparaison d’images (perceptual diff)
• Développé en interne chez LesFurets.com :
➡ https://github.com/lesfurets/zeno-pixel
• Il existe une conférence dédiée par Matthieu Fourtina

Zeno Pixel
• Screenshots automatiques des pages du site
• Cross-environment (Stage, Pre-Prod, Prod)
• Cross-device (Desktop, Mobile,Tablet)
• Comparaisons des versions de chaque page
• Calcul des différences graphiques

Zeno Pixel

Mise En Production
• Réalisée de A à Z par un seul développeur
• Automatisée via Jenkins :
➡ Création de la Release Branche
➡ Déploiement de Release Branche
➡ Merge de la Release Branche dans le master
➡ Création et diffusion de la Release Note

Infrastructure As Code
Toutes les modifications de configuration sont historisées
Les bugs de configuration sont des bugs de code

Déploiement
Tout le déploiement est fait avec 0 downtime en utilisant un
système Blue / Green

Git Flow Résumé
48

Monitoring technique
Sondes Datadog - Indicateurs techniques

Monitoring fonctionnel
Sondes Zabbix - Indicateurs fonctionnels

Alertes & Logs
Chaque logs/traces d'erreurs arrivent par mail
depuis de chaque environnement :
• 200-1000 erreurs / jour, dont 20% depuis le JS
• 1h synthétisée = 1 mail
• 24h synthétisées = 1 mail

Post Mortem
• Work in progress
• Post Mortem sur chaque incident de Production
• Analyse de la cause profonde
• Suivi de résolution de la cause
• Actuellement 5-10 incidents mineurs par mois, ~1 major

@YourTwitterHandle@YourTwitterHandle@beastiefuretsgithub.com/lesfurets/git-octopus
Le Continuous Merge
Merge automatique !

@beastiefuretsgithub.com/lesfurets/git-octopus
master
features/f1
features/f2

master
features/f1
features/f2
merged-features

n’existe pas !git merge features/*
git octopus
github.com/lesfurets/git-octopus

Git Octopus
How it works ?

master
features/f1
features/f2
octopus √

master features/f1 features/f2
octopus √

Git Octopus
What about conflicts ?

octopus
features/new
√

octopus
features/new
x

merge-master
features/new
√

master features/f1 features/f2 features/new
merge-f1 √

merge-f2 x

Git Octopus
Avoid conflicts !
#1

octopus
features/new
#1

master features/f1 features/f2 features/new*
#1

octopus
features/new*
√
#1

Git Octopus
Remove Branch
#2

octopus
features/new
x
#2

master features/f1 features/f2 studies/new
#2

octopus
studies/new
√
#2

Git Octopus
Merge Branch
#3

octopus
features/new
x
#3

feature/f2_new
#3

master features/f1
feature/f2_new
#3

master features/f1
feature/f2_new
octopus
#3

Git Octopus
Rebase branches
#4

octopus
features/new
x
#4

#4

octopus
features/new
√
#4

Git Octopus
git conflict
#5

octopus
features/new
x
#5

octopus
features/new
x
conflict/resolutions
#5

merge-f2
#5

? merge-f2 x
#5

conflict/f2_new
#5

merge-f2
√
#5
?

octopus
√
#5

Safe Zone:
• Eviter le conﬂit (!)
• Git conﬂict
Danger Zone:
• Merge des branches (attention)
• Sortir de l’IC (le temps que ça sorte)
• Rebase l’une sur l’autre
Lors des conflits

Demo

Workﬂow chez LF.com

ticket1
ticket2
ticket3
ticket4
ticket5
features releaseslocal
ticket3
master
ticket3
ticket1
master
octopus-features
octopus-releases
Le temps de commiter 1 jour à 1 mois 1 - 2 jours
pull requests
0 - 2 jours
release

Bonnes pratiques
•Proximité des équipes
•Développements indépendants
•Bonne maitrise de Git
•Code sain
•MEPs fréquentes

Commencez chez Vous

Utilisation locale
•brew install git-octopus (or from sources)
•Si vos branches ont un nommage “features/xxx”
•On merge uniquement les branches remote
entre elles
git octopus -n origin/features/* origin/master

Peut-on mieux faire ?

La suite
•Feature: Merge Github Pull-requests
•Better documentation (please contribute)
•LesFurets :Tendre vers 1 Mep / branche

Just Do It
Tu releases ton soft au moins une fois par mois ?
Le continuous delivery n’est pas loin !
•Dans l’intégration continue (CI & QA)
•Un peu plus de devops
•Git
•Process de validation incrémentale

How Google Test Software
• Quality Engineering plutôt que  
Quality Assurance
• Création d’outils de test pour les devs
• Les devs font la QA eux même

Kanban : Evolutionary Change
• Visualisation du travail
• Limiter le travail en cours (WIP)
• Règles explicites
• Amélioration continue
• Leadership

Product Development Flow
• Travailler en ﬂux
• Gérer les ﬁles d’attentes
• Regarder le lead time plutôt que le coût
de développement
• Réduire le coût de livraison

How to measure anything
• Lié à une décision à prendre
• Poser le problème
• Beaucoup plus simple qu’on pense
112

The Phoenix project
• How to avoid experts as SPOF
• DevOps as Business enabler
• Small and motivated teams
• Resilience !
113

Continuous Delivery chez LesFurets -- Deep dive Dec 2015

Contenu connexe

En vedette

Similaire à Continuous Delivery chez LesFurets -- Deep dive Dec 2015

Dernier

Continuous Delivery chez LesFurets -- Deep dive Dec 2015