Continuous delivery

Le contexte

Organisation

L'équipe de développement est séparé en 6 streams ou feature team, avec 22 développeurs, 3 devops (automatisation et opération), 1 archi-codeur

Application

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

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

Rythme 2012 - mensuel

11 releases

L'esprit avant le daily delivery : planifier / estimer / coder / tester / release de manière mensuelle

Rythme 2014 - daily

143 releases

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

2012

L'ancienne organisation avant la mise en place du daily delivery

• Sprints scrum se terminant par une mise en production
• Build 15 minutes et 200 Selenium en 1 heure
• Du commit à la MEP : en moyenne 2 semaines
• On cherche à réduire le lead time

2014

• Livraison de ce qui est prêt à J+1
• Build 3 minutes + Selenium 10 minutes
• 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 au lieu de la durée
• Réduire le coût par release

Continuous Delivery

Jez Humble

• Build rapide
• Build robuste
• Déploiements simples et automatisés
• Monitoring de production et alertes
• Analyse des causes racines

Livrer tôt, livrer souvent

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

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

• Pas de QA : QE seulement
• 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/

Commencez par finir !

Le continuous delivery

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

Exploitation

Monitoring technique

Monitoring fonctionnel

Erreurs & logs

Les stacks arrivent par mail à partir de chaque environnement.

• 200 stacks/jour, dont 20% JS
• 1 stack ➜ 1 mail
• 1h stack ➜ 1 mail
• 24h stack ➜ 1 mail

Reporting métier

Le reporting se fait en batch via des mails (format excel) et en live via le backoffice

• Une nouvelle fonctionnalité ➜ un tracker
• Le business devient ops !

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

Validation

Outillage

Regroupement d'outils de validations manuelles et automatiques

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

Zeno

Régressions UI

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

Environnement stage

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

Environnement stage

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

Environnements features

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

Intégration continue

Intégration continue

Impacts sur la base de code

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

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

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 !

Commencez par finir !

Commencer par finir

En résumé

Livrer ce qui est prêt, livrer en parallèle

Éviter les conflits au lieu de régler les conflits