Continuous Deliver

Avant de parler du continous delivery, il est important dans un premier temps de rappeler l’intégration continue :

Quel rythme pour le continuous delivery ? Quel changement implique-t-il ?

Une des interrogations des plus intéressantes qui nous pousse à avoir cette démarche, est de nous interroger, sur la valeur à donner à des fonctionnalités développées mais non encore mise en production. La réponse, brutale et non moins réalise, est : aucune.

Un des travers que nous pouvons rencontrer encore maintenant sur les projets, est de voir les fonctionnalités s’accumuler.

Toute cette perte de temps est causée parfois par le focus mis sur le développement de nouvelles fonctionnalités sans se soucier de leur livraison… Cette perte de temps est un travers fréquent lors de l’utilisation de la méthode Scrum où la vélocité est calculé par la capacité de l’équipe à produire du code et non pas de la valeur.

Nous pourrions proposer un nouveau principe : rendre votre produit déployable plutôt que livrer de nouvelle fonctionnalités puisque toute fonctionnalité non livrée n’amène pas de valeur.

Voir aussi

• Jenkins (fork de Hudson), serveur d'intégration continue pour Java
• Tinderbox, serveur d'intégration continue de la Mozilla Foundation
• Apache Continuum, server de l'Apache Software Foundation
• Team Foundation Server, serveur Microsoft
• TeamCity

Liens externes

• Continuous Integration par Martin Fowler
• Apache Gump
• CABIE
• TeamCity
• Travis CI propose un service d'intégration continue gratuit aux projets open sources.