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
  • Anecdote
  • Fonctionnement
  1. eXtreme Programming
  2. Intégration Continue, Livraison Continue et Déploiement Continu

Intégration Continue

PreviousIntégration Continue, Livraison Continue et Déploiement ContinuNextLivraison Continue

Last updated 6 years ago

L'intégration continue permet de vérifier à chaque changement de code que celui-ci fonctionne correctement sur une environnement identique à celui de production et sans perturber les autres fonctionnalités.

En eXtreme Programming, il est recommandé d'intégrer le plus fréquemment possible de petits changements afin d'en constater les conséquences le plus rapidement possible.

Anecdote

Chez Wishtack, suite à un changement, nous avons constaté une fuite mémoire sur l'environnement d'intégration après quelques minutes.

Le diagnostic et la correction ont pris quelques secondes :

  1. Récupération de l'identifiant du changement (i.e. : commit git) ayant introduit la fuite mémoire directement depuis l'outil de Monitoring.

  2. Analyse du changement (contenu du commit).

  3. Il s'agissait d'un commit où seule une ligne avait changé pour intégrer une librairie externe victime de fuite mémoire.

  4. Nous nous sommes débarrassé de la librairie pour trouver une solution alternative.

Combien de temps et de claviers cassés cela aurait couté si la fuite avait été découverte à la livraison après plusieurs mois de développement ?

Netflix raconte une fuite mémoire assez surprenante qui leur a couté une énergie considérable :

Fonctionnement

  1. A chaque modification, le développeur Check-In son code sur le Repository.

  2. A chaque Check-In, le produit est rebuild automatiquement et les résultats sont publiés. Les résultats doivent être accessibles à toute l'équipe.

  3. En cas de succès, les tests automatisés sont exécutés et les résultats publiés.

  4. En cas de succès, les serveurs d'intégration sont mis à jour.

  5. Toutes les parties prenantes (développeurs, clients etc...) peuvent évaluer la dernière version.

Node.js in FlamesMedium
Continuous Integration
Logo