Difference between revisions of "Continuous Deliver"
| Line 10: | Line 10: | ||
| − | Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie |
+ | Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement. |
| − | Un petit rappel |
+ | Un petit rappel concernant l’intégration continue: |
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc) |
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc) |
||
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications |
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications |
||
| + | |||
| + | Pour ce faire, il nécessite de contrôler plusieurs points: |
||
| + | *Contrôler l'intégrité unitaire et fonctionnelle |
||
| + | *S'assurer de l'absence de régressions |
||
| + | *Mesurer la couverture du code |
||
| + | *Surveiller le respect des conventions de codage |
||
| + | *Signaler les erreurs de codage |
||
| + | *Générer des rapports synthétiques utiles |
||
Revision as of 19:20, 4 February 2015
Le Continous Delivery
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?
Cette problématique répond à l’utilité du concept du Continous Delivery (C.D). Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour le code que soit prêt à être déployé directement à l'équipe de production.
Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement.
Un petit rappel concernant l’intégration continue:
- Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
- les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications
Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle *S'assurer de l'absence de régressions *Mesurer la couverture du code *Surveiller le respect des conventions de codage *Signaler les erreurs de codage *Générer des rapports synthétiques utiles
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.