Le Guide Agile par Wishtack
  • Le Guide Agile par Wishtack
  • Sans Agilité
    • Bottom-up vs Top-down
    • Exemple de Régression Naturelle
  • Agile Manifesto
  • Scrum
    • Théorie et Piliers du Scrum
    • Valeurs du Scrum
    • Scrum Team
    • Artefacts
      • Product Backlog
      • Sprint Backlog
      • Increment
      • User Story
      • Epic
      • Expression du Besoin
      • Definition of Done
      • Definition of Ready
    • Evénements
      • Sprint
      • Sprint Planning
      • Stand-Up Meeting ou Daily Scrum
      • Sprint Review
      • Sprint Retrospective
      • Backlog Refinement
      • Timeboxing
    • Mesures & Outils
      • Story Points vs Temps
      • Valeur, Bugs et Chores
      • Vélocité
      • Scrum Board
      • Burn Down Chart
      • Burn Up Chart
      • Technical Debt
  • Priorisation & Planning
    • Le Modèle de Kano
    • La Méthode MoSCoW
    • Release Planning
    • User Story Mapping
  • eXtreme Programming
    • Apprendre à Conduire
    • Valeurs de l'eXtreme Programming
    • Pratiques de l'eXtreme Programming
    • Testing
    • Intégration Continue, Livraison Continue et Déploiement Continu
      • Intégration Continue
      • Livraison Continue
      • Déploiement Continu
      • Review Apps
  • Indicateurs
  • Kanban
    • Principes du Kanban
    • Workflow
    • Indicateurs et Paramètres
    • Classes of Service
  • Transformation Agile
    • Projet Pilote
    • Plan de Passage à l'Agilité
    • Le Changement
    • Contractualisation
    • Management
    • Scrum of Scrums
  • Agile at Scale
  • Transformation Etape par Etape
  • Outils
  • Quelques Liens
  • Bonus
    • The "Rong" Way to do Agile
    • Agile Causal Relations
    • Talks
Powered by GitBook
On this page
  • Blue-Green Deployment
  • Feature Toggles
  • Exemple
  1. eXtreme Programming
  2. Intégration Continue, Livraison Continue et Déploiement Continu

Livraison Continue

PreviousIntégration ContinueNextDéploiement Continu

Last updated 6 years ago

En plus de tout ce que l' propose, la Livraison Continue ajoute une dernière étape au process permettant aux parties prenantes autorisées de déployer la dernière version en production par simple clic mais également de rollback à la version précédente en cas de problème.

En plus de cette fonctionnalité, la livraison continue implique surtout une façon de concevoir et de développer les produits respectant les règles suivantes :

  • Le code de l'environnement d'intégration doit fonctionner en production.

  • L'intégralité du déploiement doit se faire automatiquement (y compris les migrations de base de données par exemple).

  • Le déploiement ne doit pas causer d'interruption de service.

  • Le rollback doit être automatisable et se faire en un clic (Pensez à la backward et forward compatibility ! e.g. : Le schéma de base de données est compatible avec la version précédente et la nouvelle version).

Continuous Delivery

Blue-Green Deployment

Le Blue-Green Deployment consiste à mettre en place deux environnements identiques : Green et Blue avec un Router en amont permettant de conduire le traffic vers Green ou Blue.

En supposant que la version actuelle du produit tourne sur l'environnement Blue, le Router conduit le traffic vers l'environnement Blue.

Au déploiement d'une nouvelle version du produit :

  1. La nouvelle version est déployée sur l'environnement Green.

  2. L'équipe de développement peut tester la nouvelle application en allant sur un nom de domaine particulier ou en modifiant leur configuration DNS ou en mettant un flag dans un header par exemple...

  3. Une fois que le déploiement est validé, l'intégralité du traffic de production est conduit vers l'environnement Green plutôt que l'environnement Blue.

Le traffic est donc toujours conduit vers un seul environnement.

En cas de rollback, il suffit de reconduire le traffic vers l'environnement précédent.

Feature Toggles

Une fonctionnalité finalisée doit être livrée en production le plus rapidement possible même si celle-ci ne doit pas encore être accessible aux utilisateurs.

L'activation de la fonctionnalité pourra se faire par configuration via des Feature Toggles.

Les Feature Toggles peuvent également servir à déployer progressivement une fonctionnalité sur une population d'utilisateurs (a.k.a. Canary Deployment).

Evitez les mécanisme de configuration de Feature Flags trop complexes ! Le déploiement de configuration devient alors "error-prone" et plus délicat que le déploiement de code.

Exemple

Sur Wishtack, nous avons implémenté la fonctionnalité permettant de participer à une cagnotte avant la fonctionnalité permettant de récupérer la somme cumulée sur la cagnotte.

Il n'était bien sûr pas envisageable d'activer la première fonctionnalité sans la deuxième pour le grand public par contre, chez Wishtack, nous pouvions déjà expérimenter la première fonctionnalité en production avec des vraies transactions.

Intégration Continue
Blue / Green Deployment by Cloud Foundry
launchdarkly.com