Livrer chaque jour ce qui est prêt chez LesFurets.com v3.1 - Ippon 201606

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

@YourTwitterHandle@YourTwitterHandle@beastiefurets@dbaeli
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

Application
• 6 formulaires complexes
• 50+ partenaires interrogés en temps réel
• Java (tomcat) & GWT (client)
• 400k LOC / 40k tests unitaires / 200 tests Selenium
• Livraison Quotidienne
• 23 Developers
• 6 Tech Leads, 1 Architecte
• 2 Ops
• 1 Manager
@beatiefurets
github.com/lesfurets

Continuous Delivery ?
Livrés en 4 mois par container !
Record à battre :-)

Etre développeur
Cycle de maturation

1995-1998 Etudiant (ENSIMAG)
▪Code jamais utilisé en production
▪Livraison: A la rache
▪Code
▪écrit: 1000 lignes/mois
▪net: +1000 lignes/mois
▪Tests: 3h/mois
▪3 lignes / secondes
PRIME A LA FONCTIONALITE

1998-2006 Codeur (Edition logicielle)
▪Livraison: Mensuelle-Annuelle (recette)
▪ Code
▪ écris 600 lignes/mois
▪ ajouté (net): +500 lignes/mois
▪utilisé 6-12 mois après finition
▪ Tests
▪ 40h (1/4 du temps)
▪ 4min / ligne
PRIME A LA QUALITE

2006-2011 Développement Agile
▪ Livraison: 15-30 jours (démo global)
▪ Code:
▪ Ecris: 400 lignes/mois
▪ Ajouté (net): +200 lignes/mois
▪ Utilisé 1-2 semaines après finition
▪ Tests:
▪ 40h (5min / ligne)
PRIME A LA LIVRAISON

2011 Lean & Continuous Delivery
▪ Livraison: J+1 (démo unitaire)
▪Code
▪Ecrit 400 lignes/mois
▪Ajouté (net) +0 lignes/mois (refactoring)
▪ Utilisé 1-2 jours après finition
▪Test
▪40h (5min / ligne)
PRIME A LA VALEUR PRODUITE

2016 Manager
D’une équipe de 25 développeurs
• 12.500 lignes par mois (risque en maintenance)
• Mes Objectifs:
• Rester sous les 1% d’inﬂation (du code)
• Livrer quand c’est prêt
• Ne travailler que sur le plus utile (priorisation)
• Garder des développeurs impliqués

Continuous Delivery
La Théorie

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

Livrer plus souvent
Retour d’expérience

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
2012 : Livraison Mensuelle

2012 : Livraison Mensuelle
Planiﬁer / estimer / coder / tester /
livrer de mensuellement
Sprints
12 releases en 2012

• Objectif 2013: livrer plus souvent (hebdo)
• Améliorations:
• Identiﬁcation de fonctionnalité livrable en avance (cherry pick)
• Build : 3 minutes (contre 15 minutes)
• Blocages:
• Selenium + Recette
• Organisation du code (trunk based dev)
• Cherry Pick sur branche de release
2013 : Livraison Hebdo

2013 : Livraison Hebdo
Planiﬁer / estimer / coder / tester
livrer chaque semaine
Sprints 1 mois + Livraison hebdo

@beastiefurets@dbaeli
branch (prod)
trunk trunk
3 - 4 semaines 1 - 4 jours5 jours
Release
Code Freeze
branch

Storie 1
branch (prod)
trunk trunk
Release
Code Freeze
branch

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch
Merge à risque

Storie 1
branch (prod)
trunk trunk
Storie 2
Release
Code Freeze
branch
1 semaine
Storie 3

• Objectif 2014: Livraison journalière
• Améliorations:
• Préparation branche release auto, pas de dev non terminé en release
• Selenium : 10 minutes + Zeno (regressions graphiques)
• Blocages:
• Temps de release (2-3h par 1 dev)
• Risque par release (15jh de travail par release)
2014: Livraison Quotidienne

2014: Livraison Quotidienne
Livrer ce qui est prêt demain … tous les jours !
Marathon
208 releases en 2014 (déjà 150 en 2015)

ticket3
features releaseslocal
ticket3
master
ticket3
master
Le temps de commiter 1 jour à 1 mois 1 - 2 jours
pull requests
0 - 2 jours
release

ticket1
ticket3
ticket4
ticket3
master
ticket3
ticket1
master
pull requests
0 - 2 jours
release

octopus-features
ticket1
ticket3
ticket4
ticket3
master
ticket3
ticket1
master
pull requests
0 - 2 jours
release

ticket1
ticket2
ticket3
ticket4
ticket5
ticket3
master
ticket3
ticket1
master
octopus-features
octopus-releases
pull requests
0 - 2 jours
release

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 !)
➡ MVP devient naturel pour décider des gros projets

Vue du métier : 2014+
• 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

Objectif 2016 - Par feature
Livrer ce qui est prêt aujourd’hui … tous les jours !
Marathon
250+ releases en 2015 (déjà 150+ en 2016)

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"
Modifications par Releases
Par Release
• 5 - 6 Tickets
• >150 lignes
• Avec des exceptions
Objectif:
• Eviter les commits de >100 lignes

Livraison Continue – Jours / Heures

Mise en oeuvre

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

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

Environnement Staging
• 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é

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

Théorie v2

Kanban Games
•GetKanban !
Découverte des principes Kanban
Contexte : équipe de développement
• KanbanZine !
Découverte des principes Kanban
Contexte : fabrication d’un magazine

LIVRES
• KANBAN by D.Anderson
• PRODUCT DEVELOPMENT FLOW by Don Reinertsen
• LEAN ENTERPRISE by Humble,Molesky,O'Reilly
• KANBAN POUR L’IT by L.Morisseau
• PREMIER KANBAN by J.Boeg
• THIS IS LEAN by N.Modig, P.Ahlstrom
• SLACK by Tom DeMarco
• KANBAN FROM THE INSIDE by M.Burrows

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

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

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

How to measure anything
•D’abord identiﬁer la décision à prendre
•Identiﬁer l’information manquante
•Mesurer uniquement cette information
•Beaucoup plus simple qu’on pense

Lean Enterprise
•Orient
•Alternative to Command and Control
•Enterprise Portfolio
•Explore Uncertainty
•Discover opportunities
•Exploit
•Continuous Delivery, Cost of Delay
•Transform
•Embrace Lean Thinking, Rethinking the IT Mindset

79
LesFurets.com LeanKanban.fr29, 30 Novembre 2016
www.leankanban.fr

@dbaeli
@beastiefurets
MERCI !

Livrer chaque jour ce qui est prêt chez LesFurets.com v3.1 - Ippon 201606

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (11)

Similaire à Livrer chaque jour ce qui est prêt chez LesFurets.com v3.1 - Ippon 201606

Similaire à Livrer chaque jour ce qui est prêt chez LesFurets.com v3.1 - Ippon 201606 (20)

Dernier

Dernier (6)

Livrer chaque jour ce qui est prêt chez LesFurets.com v3.1 - Ippon 201606