Continuous Delivery : développement logiciel dans un pipeline
La Continuous Delivery (en français : « livraison continue ») est un concept novateur de développement logiciel de plus en plus populaire. Dans le cadre de la Continuous Delivery, les étapes de production que sont le développement, le contrôle qualité et la livraison ne sont pas définitives et se répètent automatiquement au cours du processus de développement pour former une boucle basée sur ce qu’on appelle un pipeline de Continuous Delivery. L’avantage de cette méthode est qu’elle vous permet de soumettre graduellement et à intervalles réguliers les produits logiciels à un contrôle qualité et de les livrer alors que vous travaillez encore sur le produit. Vous bénéficiez ainsi d’un feed-back constant dans le pipeline, ce qui vous permet d’améliorer immédiatement le logiciel de façon ciblée après chaque modification du code source.
La Continuous Delivery est un modèle utilisé dans le développement logiciel afin d’effectuer en parallèle et à brefs intervalles le développement, la livraison, le feed-back et la gestion de la qualité dans une boucle continue. Le développement gagne ainsi en efficacité et le client reçoit le produit de façon précoce même s’il n’est pas achevé. La Continuous Delivery apporte aux développeurs un feed-back grâce à des tests automatisés qui vérifient en général le build après chaque modification du code source.
La Continuous Delivery décrit donc un processus à double sens qui réunit et automatise le développement, la livraison, le feed-back et la gestion de la qualité, vous permettant ainsi de réduire à un minimum les étapes de travail longues et coûteuses.
Les avantages de la Continuous Delivery
Dans le cas d’un développement logiciel classique, le produit final est uniquement livré lorsqu’il comprend toutes les caractéristiques ciblées, se déroule sans accroc et ne comporte aucune erreur grave lors du contrôle de la qualité. Le développeur fournit ensuite des correctifs et des mises à niveau pour le logiciel à des intervalles plus ou moins réguliers. Dans le cas d’une Continuous Delivery, le produit est livré au client à un stade de développement bien antérieur, alors que le développeur travaille encore sur le programme. La version préliminaire contient souvent uniquement les principales fonctionnalités du logiciel, que le client peut alors tester dans un environnement réel. Le client (ou le testeur du logiciel) joue donc un rôle essentiel dans le contrôle de la qualité.
Le feed-back ainsi obtenu permet au développeur d’améliorer les fonctionnalités existantes alors que le programme est toujours en cours de développement. Il peut également obtenir de précieuses informations sur les futures fonctionnalités à développer. En l’absence de Continuous Delivery, ce processus peut s’avérer être assez pénible et source de mécontentement, aussi bien pour le développeur que pour le client : de manière générale, le client attend un produit fini répondant à ses exigences et à ses souhaits, mais le développeur ne sait pas encore exactement ce qu’ils sont. Si la communication sur l’état du développement du produit intervient de façon précoce, il est alors plus facile de tenir compte des souhaits du client et d’éviter les erreurs. Ce principe peut être représenté sous la forme d’un cercle :
Les trois domaines que sont le développement, le contrôle qualité et la production se substituent donc l’un à l’autre au cours d’un processus unique et s’enchaînent sans cesse. Le produit traverse ainsi continuellement les différentes phases et est amélioré en permanence. Si le nombre de clients est important, ce processus nécessite une automatisation. C’est là qu’intervient la Continuous Delivery en automatisant l’intégralité du processus.
La Continuous Delivery permet de tester en temps réel toutes les modifications ou extensions du logiciel (c.-à-d. toute modification apportée au code source) pour recueillir un feed-back. Il est ainsi possible de détecter rapidement les effets indésirables afin d’intervenir à un stade encore relativement précoce. La Continuous Delivery se révèle notamment très utile en cas de bug pour déterminer avec plus de facilité quelle portion de code est à l’origine de l’erreur. Sans cette méthode, la recherche de problème est souvent très laborieuse.
Sur son parcours jusqu’au client, le logiciel passe donc par une étape intermédiaire que l’on appelle pipeline de Continuous Delivery, qui permet de réaliser des tests manuels ou automatisés. Chaque phase de test aboutit à une nouvelle version du logiciel (généralement nommée « version bêta » ou « Nightly Build », c’est-à-dire une version créée pendant la nuit). Cette nouvelle version est une nouvelle fois passée dans le pipeline. Ce n’est que lorsque le logiciel a réussi tous les tests et donné lieu à un feed-back satisfaisant qu’une version « stable » est créée et que le produit est officiellement publié (on appelle cette procédure, ainsi que l’application publiée à proprement parler, « mise à disposition »). La probabilité que le client reçoive un produit exempt d’erreur dans ce cas est nettement supérieure.
Le principal avantage de la Continuous Delivery est que le processus automatisé profite aussi bien au client qu’au développeur. Pour le client, le produit sera livré plus rapidement et, en règle générale, sans erreurs. Pour le développeur, les « tests en situation réelle » sont nettement plus efficaces qu’un bêta-test effectué en interne, car ils fournissent des données et des informations plus utiles. Ce modèle permet d’augmenter nettement la flexibilité sur l’ensemble du processus de développement et de réduire le risque de publier un logiciel comportant des erreurs à un minimum.
Aperçu des avantages et des inconvénients de la Continuous Delivery
| Avantages | Inconvénients |
|---|---|
| Les erreurs du logiciel peuvent être identifiées et corrigées de façon nettement plus efficace au cours du processus de développement. | Facteur de coût : un serveur d’intégration plus puissant et plus fiable est nécessaire pour les tests automatisés afin de garantir une livraison efficace et sûre du produit. |
| L’effort investi dans une mise à disposition du logiciel classique est en grande partie supprimé. Les développeurs peuvent se concentrer pleinement sur le développement à proprement parler. | Les tests automatisés doivent être écrits et fonctionner à la perfection. Les tests erronés peuvent entraîner d’importants dommages lors du contrôle de la qualité. |
| Le pipeline de Continuous Delivery facilite énormément la recherche d’erreurs pour les développeurs. | Nécessite une bonne coordination au sein de l’équipe, car les modifications apportées au code doivent être regroupées fréquemment et de façon efficace. |
| Les coûts engendrés par les processus de test sont inférieurs à d’autres processus (par ex. en cas d’alpha-test et de bêta-test). | Nécessite une communication efficace et continue avec les clients et leurs systèmes cibles. |
| Le contrôle de la qualité peut consacrer davantage de ressources à l’amélioration conceptuelle plutôt qu’à l’amélioration technique du logiciel. | Le client attend des mises à jour et des améliorations régulières. Le projet logiciel peut rarement être « mis en pause ». |
| En principe, le développement du logiciel progresse plus rapidement, car les développeurs sont libérés d’une partie de leur travail grâce à des processus de mise à disposition en grande partie automatisés, qui engendrent un nombre moins important de pauses. | La livraison des nouveautés, des améliorations et des modifications apportées au produit est toujours effectuée manuellement. Afin d’automatiser ce processus, il faut passer à un Continuous Deployment. |
| Des mises à disposition plus rapides et plus fréquentes permettent d’accélérer la boucle de feed-back et d’amélioration. | Le client doit être disposé à utiliser un logiciel qui est encore en cours de développement et à fournir un feed-back. |
| Le développeur est moins sous pression en cas de modification apportée au code source, car l’erreur peut être trouvée rapidement. Le travail est ainsi plus motivant et plus inspirant. |
Phases du pipeline de la Continuous Delivery
La modification du code déclenche le pipeline de Continuous Delivery et lance l’exécution du processus de test. Voici les phases traversées par le pipeline de Continuous Delivery :
- Commit Stage : cette première phase de test consiste à contrôler la version du logiciel, à monter ou compiler les composantes du logiciel et à effectuer les tests unitaires nécessaires. Cette phase s’achève après la réussite des tests. Les artefacts binaires des composantes logicielles sont regroupés dans un bundle et placés dans un dépôt. Ce paquet est ensuite décisif pour le fonctionnement du pipeline, car il détermine la version du logiciel ; il contient d’autre part la quantité de données qui sera installée ultérieurement sur le système cible. Les résultats des tests de la phase Commit Stage peuvent être attribués aux modifications spécifiques du code source, conférant un avantage majeur à la Continuous Delivery.
- Acceptance Test Stage : Les tests d’acceptation sont effectués au cours de cette deuxième phase. Ils comprennent notamment les tests d’intégration (l’interaction entre les composantes est-elle fonctionnelle ?) et les tests système nécessaires (le logiciel fonctionne-t-il côté utilisateur ?). D’autres tests facultatifs peuvent par ailleurs intervenir à la phase Acceptance Test Stage, tels que les tests de performance et d’autres tests contrôlant les exigences non fonctionnelles du logiciel. Le bundle créé à la phase précédente est utilisé pour la phase Acceptance Test Stage et est installé dans l’environnement de test adapté.
- Les éventuelles erreurs ou complications rencontrées lors de ces phases sont documentées et, si nécessaire, envoyées sous forme de feed-back au développeur. Cet envoi peut s’effectuer par e-mail, à l’aide d’un programme de messagerie ou d’outils spécifiques (voir ci-dessous). Le pipeline étant déclenché à chaque modification de code, les messages d’erreur ou les régressions portent toujours sur la dernière version. Le développeur peut ainsi réagir rapidement et efficacement en corrigeant d’éventuelles erreurs ou en améliorant le code erroné.
- Si nécessaire, des tests manuels sont alors effectués. Pour ces tests, le pipeline utilise également le bundle de la première phase et l’installe dans un environnement de test adapté.
- Si tous les tests sont achevés avec un feed-back positif, le paquet peut être installé manuellement sur le système cible. Il suffit généralement d’appuyer sur un bouton. Si cette étape est également automatisée, on parle alors de Continuous Deployment.
Continuous Integration vs. Continuous Delivery
On a souvent tendance à rapprocher le terme Continuous Integration à la Continuous Delivery. Une différence majeure réside toutefois dans l’étendue de ces modèles : alors que la Continuous Integration désigne l’automatisation du processus de test et partage la majorité de son pipeline avec celui de la Continuous Delivery, cette dernière élargit le concept et prévoit également l’automatisation du processus de mise à disposition du logiciel. La Continuous Delivery vient ainsi compléter le modèle de la Continuous Integration avec l’utilisateur final puisqu’il livre le projet en parallèle des tests.
Le choix d’un développeur pour une simple Continuous Integration ou pour une Continuous Delivery avec un processus de développement étendu dépend de la planification du développement, de l’équipe de développement et de la clientèle. Nous comparons les deux concepts ci-après :
| Continuous Integration (CI) | Continuous Delivery (CD) |
|---|---|
| Processus de test automatisé qui soumet chaque modification du code source à un contrôle critique | Élargit le processus de test au processus de livraison. Les nouveautés et les modifications apportées au code sont automatiquement transmises à l’utilisateur final. |
| L’équipe doit écrire des tests automatisés pour chaque nouvelle caractéristique, chaque amélioration et chaque modification du code. | L’efficacité de ces tests est particulièrement essentielle pour la CD puisque les résultats sont directement transmis à l’utilisateur final. |
| Exige un serveur d’intégration continue dédié qui surveille et applique les tests automatisés. | Dans la mesure du possible, l’installation sur le système cible doit s’effectuer de façon automatisée, ce qui implique des exigences importantes en matière de serveur. |
| Les développeurs doivent regrouper continuellement les modifications qu’ils apportent au code. | Par ailleurs, les développeurs doivent entretenir un bon contact avec le client et faire preuve de la plus grande transparence possible concernant le logiciel. |
| Nécessite des ressources relativement importantes pour garantir la qualité du produit à la livraison. | Ces ressources sont encore plus importantes en cas de CD. Elles permettent de livrer le produit à un stade bien antérieur et de le soumettre à de « véritables » tests. |
| Le développement à proprement parler est plus efficace, mais est souvent interrompu par des mises à disposition manuelles. | Le développement est continu puisqu’une grande partie du processus de mise à disposition est également automatisé. |
Outils de Continuous Delivery (Continuous Delivery tools) réputés
Différents programmes faciliteront votre passage à la Continuous Delivery. Nous vous en présentons quatre.
Jenkins
Jenkins est une application web permettant l’intégration continue des composantes des logiciels. Basée sur Java, Jenkins fonctionne dans n’importe quel conteneur EJB et comprend différents outils de build (Apache Ant, Maven/Gradle, CVS, Subversion, Git etc.), mais aussi des processus de test automatisés essentiels pour la Continuous Delivery (JUnit, Emma). Des plug-ins facultatifs garantissent la compatibilité avec d’autres compilateurs. L’interface de programmation basée sur REST permet de plus à d’autres programmes d’accéder à Jenkins. Jenkins est un programme open source gratuit. Il est principalement recommandé aux débutants, car l’interface et les fonctionnalités sont conçues de façon très conviviale pour les novices.
Découvrez comment fonctionne cette application étape par étape dans notre tutoriel Jenkins.
CircleCI
CircleCI est une application de Continuous Integration, Delivery et Deployment également basée en ligne. CircleCI travaille en priorité avec GitHub, GitHub Enterprise et Bitbucket. Par ailleurs, la plateforme propose de nombreuses fonctionnalités pratiques, telles qu’une gestion des commandes, une gestion des ressources, une compatibilité avec Docker et tous les langages de programmation connus, une mise en cache sécurisée, une analyse des données avec des statistiques et des concepts de sécurité complets. En 2017, CircleCI s’est vu décerner la récompense « Leader in Continuous Integration » décernée par Forrester. Le premier conteneur est gratuit, le second comme les suivants coûtent chacun 50 dollars US par mois.
Microsoft Team Foundation Server
Microsoft Team Foundation Server (TFS) est un outil de collaboration pour les projets logiciels devant être planifiés, créés puis gérés de façon conjointe. TFS est le successeur non officiel de Microsofts Visual SourceSafe. Afin de permettre un travail collaboratif sur un projet logiciel, TFS supporte différents processus de développement dont CMMI, le développement logiciel agile et Scrum. Pour faciliter le travail, les programmes Office tels que Word et Excel sont intégrés à TFS pour éviter d’avoir à passer de TFS à un autre programme.
Différentes caractéristiques vous permettant de construire un pipeline sont disponibles pour la Continuous Integration, la Continuous Delivery et le Continuous Deployment. En principe, TFS divise le processus global en plusieurs sections : contrôle de la version, build, rapports et gestion des utilisateurs.
Les équipes constituées de 5 personnes au maximum peuvent utiliser la version Express gratuite ; les équipes plus importantes devront acquérir la version commerciale qui coûte environ 6 dollars US par utilisateur et par mois. Il vous sera généralement également nécessaire d’acquérir une licence de serveur. Vous pouvez faire l’acquisition de TFS sans abonnement mensuel ; pour cela, vous devrez toutefois contacter un revendeur local. Le prix semble varier de 500 à 700 euros.
Codeship
Codeship est une plateforme SaaS pour la Continuous Integration (vs Continuous Delivery) dont l’étendue s’adapte aux besoins de l’utilisateur. Codeship supporte GitLab, GitHub et Bitbucket. Les fonctionnalités disponibles dépendent alors des modalités de paiement choisies : dans la version gratuite, Codeship offre un environnement de CI préparamétré et prend également en charge le workflow applicable pour la CI/CD. D’autre part, la version payante propose une mise en cache efficace et la réalisation des tests de builds en parallèle dans des conteneurs séparés et préconfigurés. La version gratuite permet jusqu’à 100 builds par mois pour un build courant ainsi qu’un pipeline de test. Il convient de noter ici l’absence de limite pour les projets, les utilisateurs et les équipes.
Disponible à partir d’env. 45 euros/mois (le prix dépend de la taille de l’équipe), la version payante « Codeship Basic » vous permettra d’exploiter pleinement ce programme. La seconde version payante « Codeship Pro » étend encore la liste des fonctionnalités avec une compatibilité Docker, le « contrôle complet » sur l’environnement de build, des builds locaux et un meilleur contrôle sur le workflow. D’autre part, un plus grand nombre d’outils sont accessibles et la Continuous Integration vs Continuous Delivery est encore plus efficace et transparente. Selon le nombre de builds parallèles, Codeship Pro coûte environ 70 euros par mois.