Continuous delivery

Le contexte

Organisation

L'équipe de développement de LesFurets.com

• 6 streams ou feature teams
• 22 développeurs
• 3 devops (automatisation et opération)
• 1 archi-codeur
• 8 business analysts / product owners

Application

Le site est constitué d'une application front et une application backoffice

• 5 produits
• 1 code base avec 400k loc
• 40k tests unitaires et 200 tests Selenium
• 10+ serveurs

Rythme 2012 - mensuel

11 releases

L'esprit :
planifier / estimer / coder / tester / livrer de manière mensuelle

Rythme 2014 - quotidien

171 releases

L'esprit :
livrer ce qui est prêt le jour suivant

2012

L'ancienne organisation en scrum classique

• Build 15 minutes et 200 Selenium en 1 heure
• Sprints d'un mois se terminant par une mise en production
• Du commit à la MEP : en moyenne 2 semaines
• Non satisfaisant pour un site Web

2014

• Build 3 minutes + Selenium 10 minutes
• Livraison de ce qui est prêt à J+1
• Du commit à la MEP : en moyenne 5 jours

Quelques lectures

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

Product development flow

Don Reinertsen

• Travailler en flux
• Gérer les files de d'attentes
• Regarder le lead time plutôt que le coût de développement
• Réduire le coût de livraison

Continuous Delivery

Jez Humble

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

Kanban : Evolutionary change

David Anderson

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

How Google Test Software

James Whitaker, Jason Arbon, Jeff Carollo

• Quality Engineering plutôt que Quality Assurance
• Création d'outils de test pour les dev
• Les dev font la QA eux même

Git Flow

Vincent Driessen

• Un puissant modèle de branches git
• http://nvie.com/posts/a-successful-git-branching-model/

Livrer tôt, livrer souvent

Source: http://paulhammant.com/2013/03/13/facebook-tbd-take-2/

Commencer par finir !

Le continuous delivery

• 5. Exploitation
• 4. Mise en production
• 3. Validation
• 2. Intégration continue
• 1. Implémentation

Exploitation

Monitoring technique

Monitoring fonctionnel

Erreurs & logs

Les logs/traces d'erreurs arrivent par mail à partir de chaque environnement.

• 200 erreurs/jour, dont 20% depuis le JavaScript
• 1 erreur ➜ 1 mail
• 1h synthétisée ➜ 1 mail
• 24h synthétisées ➜ 1 mail

Mise en production

Mise en production

Automatiser

"Infrastructure as code"

Déploiement

Tout le déploiement est fait avec 0 downtime en utilisant un système style blue / green.

• Environnement de production dupliqué
• Loadbalancer en entrée

Déploiement Blue / Green

Validation

Outillage

Regroupement d'outils de validations manuelles et automatiques

• Tests unitaires, d'intégration et Selenium
• Code review
• Showcase et validation fonctionnelle
• Régressions UI : Zeno
• Tests manuels exploratoires

Zeno

Régressions UI

Outil développé par la QE chez LesFurets.com pour faire de la comparaison d'image (perceptual diff)

• 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

Environnements features

• 1 environnement par feature
• Déploiement dans un environnement isolé (Docker)
• Isolation pour les tests, les Selenium, etc.

Environnement stage

• Recette en continue
• Seleniums sur le regroupement
• Suivi des logs plus facile
• Effets de bord des features

Environnements de déploiement

Rassemble les branches features sur un même environnement grâce à l'octopus

Intégration continue

Intégration continue

Modèle de branches

• Développement trunk
• Développement trunk avec release branche
• Features branches mergée en continu
• Mise en production à partir d'une release branche
• Release branche créée à partir des features branches qui sont prêtes

Intégration continue

Impacts sur la base de code

Gérer les conflits en feature branche

Éviter les conflits

La facilité de merge témoigne de la santé du code

SOLID ➜ Single responsibility principle

En général, il est plus facile d'éviter un conflit que de le régler

Intégration continue

Features branches

Intégration continue

L'intégration continue (combinaison de TeamCity et Jenkins) effectue à chaque commit :

• Compilation
• Tests automatisés
• Merge des feature branches (octopus)

➜ On fait du continuous merge avec l'octopus

Octopus

Continuous merge

Octopus

Continuous merge

Octopus

Continuous merge

Octopus

Continuous merge

Outils de merge en continu développé chez LesFurets.com

➜ https://github.com/lesfurets/git-octopus

• Construction de l'environnement de test
• Détection des conflits entre branches
• Plug / unplug les branches facilement

Octopus

Continuous merge

L'octopus est utilisé pour merger en continu toutes les features, mais aussi pour créer la release branche avec un sous ensemble de features

L'octopus à l'oeuvre

30 branches features et plus !