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 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.

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.

1. 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.
2. 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é.
3. 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é.
4. 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é.
5. 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.

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 :

Différents programmes faciliteront votre passage à la Continuous Delivery. Nous vous en présentons quatre.

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.

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 (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 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.