La Con­ti­nuous Delivery (en français : « livraison continue ») est un concept novateur de dé­ve­lop­pe­ment logiciel de plus en plus populaire. Dans le cadre de la Con­ti­nuous Delivery, les étapes de pro­duc­tion que sont le dé­ve­lop­pe­ment, le contrôle qualité et la livraison ne sont pas dé­fi­ni­tives et se répètent au­to­ma­ti­que­ment au cours du processus de dé­ve­lop­pe­ment pour former une boucle basée sur ce qu’on appelle un pipeline de Con­ti­nuous Delivery. L’avantage de cette méthode est qu’elle vous permet de soumettre gra­duel­le­ment et à in­ter­valles réguliers les produits logiciels à un contrôle qualité et de les livrer alors que vous tra­vail­lez encore sur le produit. Vous bé­né­fi­ciez ainsi d’un feed-back constant dans le pipeline, ce qui vous permet d’améliorer im­mé­dia­te­ment le logiciel de façon ciblée après chaque mo­di­fi­ca­tion du code source.

Dé­fi­ni­tion

La Con­ti­nuous Delivery est un modèle utilisé dans le dé­ve­lop­pe­ment logiciel afin d’effectuer en parallèle et à brefs in­ter­valles le dé­ve­lop­pe­ment, la livraison, le feed-back et la gestion de la qualité dans une boucle continue. Le dé­ve­lop­pe­ment gagne ainsi en ef­fi­ca­cité et le client reçoit le produit de façon précoce même s’il n’est pas achevé. La Con­ti­nuous Delivery apporte aux dé­ve­lop­peurs un feed-back grâce à des tests au­to­ma­ti­sés qui vérifient en général le build après chaque mo­di­fi­ca­tion du code source.

La Con­ti­nuous Delivery décrit donc un processus à double sens qui réunit et au­to­ma­tise le dé­ve­lop­pe­ment, la livraison, le feed-back et la gestion de la qualité, vous per­met­tant ainsi de réduire à un minimum les étapes de travail longues et coûteuses.

Les avantages de la Con­ti­nuous Delivery

Dans le cas d’un dé­ve­lop­pe­ment logiciel classique, le produit final est uni­que­ment livré lorsqu’il comprend toutes les ca­rac­té­ris­tiques ciblées, se déroule sans accroc et ne comporte aucune erreur grave lors du contrôle de la qualité. Le dé­ve­lop­peur fournit ensuite des cor­rec­tifs et des mises à niveau pour le logiciel à des in­ter­valles plus ou moins réguliers. Dans le cas d’une Con­ti­nuous Delivery, le produit est livré au client à un stade de dé­ve­lop­pe­ment bien antérieur, alors que le dé­ve­lop­peur travaille encore sur le programme. La version pré­li­mi­naire contient souvent uni­que­ment les prin­ci­pales fonc­tion­na­li­tés du logiciel, que le client peut alors tester dans un en­vi­ron­ne­ment 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é­ve­lop­peur d’améliorer les fonc­tion­na­li­tés exis­tantes alors que le programme est toujours en cours de dé­ve­lop­pe­ment. Il peut également obtenir de pré­cieuses in­for­ma­tions sur les futures fonc­tion­na­li­tés à dé­ve­lop­per. En l’absence de Con­ti­nuous Delivery, ce processus peut s’avérer être assez pénible et source de mé­con­ten­te­ment, aussi bien pour le dé­ve­lop­peur 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é­ve­lop­peur ne sait pas encore exac­te­ment ce qu’ils sont. Si la com­mu­ni­ca­tion sur l’état du dé­ve­lop­pe­ment du produit in­ter­vient 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 re­pré­senté sous la forme d’un cercle :

Image: Cycle développement, contrôle qualité, production
La Con­ti­nuous Delivery au­to­ma­tise le cycle des processus de dé­ve­lop­pe­ment, de contrôle qualité et de pro­duc­tion.

Les trois domaines que sont le dé­ve­lop­pe­ment, le contrôle qualité et la pro­duc­tion se subs­ti­tuent donc l’un à l’autre au cours d’un processus unique et s’en­chaî­nent sans cesse. Le produit traverse ainsi con­ti­nuel­le­ment les dif­fé­rentes phases et est amélioré en per­ma­nence. Si le nombre de clients est important, ce processus nécessite une au­to­ma­ti­sa­tion. C’est là qu’in­ter­vient la Con­ti­nuous Delivery en au­to­ma­ti­sant l’in­té­gra­lité du processus.

La Con­ti­nuous Delivery permet de tester en temps réel toutes les mo­di­fi­ca­tions ou ex­ten­sions du logiciel (c.-à-d. toute mo­di­fi­ca­tion apportée au code source) pour re­cueil­lir un feed-back. Il est ainsi possible de détecter ra­pi­de­ment les effets in­dé­si­rables afin d’in­ter­ve­nir à un stade encore re­la­ti­ve­ment précoce. La Con­ti­nuous Delivery se révèle notamment très utile en cas de bug pour dé­ter­mi­ner 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 la­bo­rieuse.

Sur son parcours jusqu’au client, le logiciel passe donc par une étape in­ter­mé­diaire que l’on appelle pipeline de Con­ti­nuous Delivery, qui permet de réaliser des tests manuels ou au­to­ma­ti­sés. Chaque phase de test aboutit à une nouvelle version du logiciel (gé­né­ra­le­ment 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 sa­tis­fai­sant qu’une version « stable » est créée et que le produit est of­fi­ciel­le­ment publié (on appelle cette procédure, ainsi que l’ap­pli­ca­tion publiée à pro­pre­ment parler, « mise à dis­po­si­tion »). La pro­ba­bi­lité que le client reçoive un produit exempt d’erreur dans ce cas est nettement su­pé­rieure.

Image: Pipeline de Continuous Delivery en cas de modification du code
Le pipeline de Con­ti­nuous Delivery est déclenché à chaque fois que des mo­di­fi­ca­tions sont apportées au code.

Le principal avantage de la Con­ti­nuous Delivery est que le processus au­to­ma­tisé profite aussi bien au client qu’au dé­ve­lop­peur. Pour le client, le produit sera livré plus ra­pi­de­ment et, en règle générale, sans erreurs. Pour le dé­ve­lop­peur, les « tests en situation réelle » sont nettement plus efficaces qu’un bêta-test effectué en interne, car ils four­nis­sent des données et des in­for­ma­tions plus utiles. Ce modèle permet d’augmenter nettement la flexi­bi­lité sur l’ensemble du processus de dé­ve­lop­pe­ment et de réduire le risque de publier un logiciel com­por­tant des erreurs à un minimum.

Aperçu des avantages et des in­con­vé­nients de la Con­ti­nuous Delivery

Avantages In­con­vé­nients
Les erreurs du logiciel peuvent être iden­ti­fiées et corrigées de façon nettement plus efficace au cours du processus de dé­ve­lop­pe­ment. Facteur de coût : un serveur d’in­té­gra­tion plus puissant et plus fiable est né­ces­saire pour les tests au­to­ma­ti­sés afin de garantir une livraison efficace et sûre du produit.
L’effort investi dans une mise à dis­po­si­tion du logiciel classique est en grande partie supprimé. Les dé­ve­lop­peurs peuvent se con­cen­trer plei­ne­ment sur le dé­ve­lop­pe­ment à pro­pre­ment parler. Les tests au­to­ma­ti­sés doivent être écrits et fonc­tion­ner à la per­fec­tion. Les tests erronés peuvent entraîner d’im­por­tants dommages lors du contrôle de la qualité.
Le pipeline de Con­ti­nuous Delivery facilite énor­mé­ment la recherche d’erreurs pour les dé­ve­lop­peurs. Nécessite une bonne coor­di­na­tion au sein de l’équipe, car les mo­di­fi­ca­tions apportées au code doivent être re­grou­pées fré­quem­ment et de façon efficace.
Les coûts engendrés par les processus de test sont in­fé­rieurs à d’autres processus (par ex. en cas d’alpha-test et de bêta-test). Nécessite une com­mu­ni­ca­tion efficace et continue avec les clients et leurs systèmes cibles.
Le contrôle de la qualité peut consacrer davantage de res­sources à l’amé­lio­ra­tion con­cep­tuelle plutôt qu’à l’amé­lio­ra­tion technique du logiciel. Le client attend des mises à jour et des amé­lio­ra­tions ré­gu­lières. Le projet logiciel peut rarement être « mis en pause ».
En principe, le dé­ve­lop­pe­ment du logiciel progresse plus ra­pi­de­ment, car les dé­ve­lop­peurs sont libérés d’une partie de leur travail grâce à des processus de mise à dis­po­si­tion en grande partie au­to­ma­ti­sés, qui en­gendrent un nombre moins important de pauses. La livraison des nou­veau­tés, des amé­lio­ra­tions et des mo­di­fi­ca­tions apportées au produit est toujours effectuée ma­nuel­le­ment. Afin d’au­to­ma­ti­ser ce processus, il faut passer à un Con­ti­nuous De­ploy­ment.
Des mises à dis­po­si­tion plus rapides et plus fré­quentes per­met­tent d’accélérer la boucle de feed-back et d’amé­lio­ra­tion. Le client doit être disposé à utiliser un logiciel qui est encore en cours de dé­ve­lop­pe­ment et à fournir un feed-back.
Le dé­ve­lop­peur est moins sous pression en cas de mo­di­fi­ca­tion apportée au code source, car l’erreur peut être trouvée ra­pi­de­ment. Le travail est ainsi plus motivant et plus inspirant.  

Phases du pipeline de la Con­ti­nuous Delivery

La mo­di­fi­ca­tion du code déclenche le pipeline de Con­ti­nuous Delivery et lance l’exécution du processus de test. Voici les phases tra­ver­sées par le pipeline de Con­ti­nuous Delivery :

Image: Phases du pipeline de Continuous Delivery
Le pipeline de Con­ti­nuous Delivery traverse un certain nombre de phases à chaque mo­di­fi­ca­tion apportée au code.
  1. Commit Stage : cette première phase de test consiste à contrôler la version du logiciel, à monter ou compiler les com­po­santes du logiciel et à effectuer les tests unitaires né­ces­saires. Cette phase s’achève après la réussite des tests. Les artefacts binaires des com­po­santes lo­gi­cielles sont regroupés dans un bundle et placés dans un dépôt. Ce paquet est ensuite décisif pour le fonc­tion­ne­ment du pipeline, car il détermine la version du logiciel ; il contient d’autre part la quantité de données qui sera installée ul­té­rieu­re­ment sur le système cible. Les résultats des tests de la phase Commit Stage peuvent être attribués aux mo­di­fi­ca­tions spé­ci­fiques du code source, conférant un avantage majeur à la Con­ti­nuous Delivery.
  2. Ac­cep­tance Test Stage : Les tests d’ac­cep­ta­tion sont effectués au cours de cette deuxième phase. Ils com­pren­nent notamment les tests d’in­té­gra­tion (l’in­te­rac­tion entre les com­po­santes est-elle fonc­tion­nelle ?) et les tests système né­ces­saires (le logiciel fonc­tionne-t-il côté uti­li­sa­teur ?). D’autres tests fa­cul­ta­tifs peuvent par ailleurs in­ter­ve­nir à la phase Ac­cep­tance Test Stage, tels que les tests de per­for­mance et d’autres tests con­trô­lant les exigences non fonc­tion­nelles du logiciel. Le bundle créé à la phase pré­cé­dente est utilisé pour la phase Ac­cep­tance Test Stage et est installé dans l’en­vi­ron­ne­ment de test adapté.
  3. Les éven­tuelles erreurs ou com­pli­ca­tions ren­con­trées lors de ces phases sont do­cu­men­tées et, si né­ces­saire, envoyées sous forme de feed-back au dé­ve­lop­peur. Cet envoi peut s’effectuer par e-mail, à l’aide d’un programme de mes­sa­ge­rie ou d’outils spé­ci­fiques (voir ci-dessous). Le pipeline étant déclenché à chaque mo­di­fi­ca­tion de code, les messages d’erreur ou les ré­gres­sions portent toujours sur la dernière version. Le dé­ve­lop­peur peut ainsi réagir ra­pi­de­ment et ef­fi­ca­ce­ment en cor­ri­geant d’éven­tuelles erreurs ou en amé­lio­rant le code erroné.
  4. Si né­ces­saire, 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 en­vi­ron­ne­ment de test adapté.
  5. Si tous les tests sont achevés avec un feed-back positif, le paquet peut être installé ma­nuel­le­ment sur le système cible. Il suffit gé­né­ra­le­ment d’appuyer sur un bouton. Si cette étape est également au­to­ma­ti­sée, on parle alors de Con­ti­nuous De­ploy­ment.

Con­ti­nuous In­te­gra­tion vs. Con­ti­nuous Delivery

On a souvent tendance à rap­pro­cher le terme Con­ti­nuous In­te­gra­tion à la Con­ti­nuous Delivery. Une dif­fé­rence majeure réside toutefois dans l’étendue de ces modèles : alors que la Con­ti­nuous In­te­gra­tion désigne l’au­to­ma­ti­sa­tion du processus de test et partage la majorité de son pipeline avec celui de la Con­ti­nuous Delivery, cette dernière élargit le concept et prévoit également l’au­to­ma­ti­sa­tion du processus de mise à dis­po­si­tion du logiciel. La Con­ti­nuous Delivery vient ainsi compléter le modèle de la Con­ti­nuous In­te­gra­tion avec l’uti­li­sa­teur final puisqu’il livre le projet en parallèle des tests.

Le choix d’un dé­ve­lop­peur pour une simple Con­ti­nuous In­te­gra­tion ou pour une Con­ti­nuous Delivery avec un processus de dé­ve­lop­pe­ment étendu dépend de la pla­ni­fi­ca­tion du dé­ve­lop­pe­ment, de l’équipe de dé­ve­lop­pe­ment et de la clientèle. Nous comparons les deux concepts ci-après :

Con­ti­nuous In­te­gra­tion (CI) Con­ti­nuous Delivery (CD)
Processus de test au­to­ma­tisé qui soumet chaque mo­di­fi­ca­tion du code source à un contrôle critique Élargit le processus de test au processus de livraison. Les nou­veau­tés et les mo­di­fi­ca­tions apportées au code sont au­to­ma­ti­que­ment trans­mises à l’uti­li­sa­teur final.
L’équipe doit écrire des tests au­to­ma­ti­sés pour chaque nouvelle ca­rac­té­ris­tique, chaque amé­lio­ra­tion et chaque mo­di­fi­ca­tion du code. L’ef­fi­ca­cité de ces tests est par­ti­cu­liè­re­ment es­sen­tielle pour la CD puisque les résultats sont di­rec­te­ment transmis à l’uti­li­sa­teur final.
Exige un serveur d’in­té­gra­tion continue dédié qui surveille et applique les tests au­to­ma­ti­sés. Dans la mesure du possible, l’ins­tal­la­tion sur le système cible doit s’effectuer de façon au­to­ma­ti­sée, ce qui implique des exigences im­por­tantes en matière de serveur.
Les dé­ve­lop­peurs doivent regrouper con­ti­nuel­le­ment les mo­di­fi­ca­tions qu’ils apportent au code. Par ailleurs, les dé­ve­lop­peurs doivent en­tre­te­nir un bon contact avec le client et faire preuve de la plus grande trans­pa­rence possible con­cer­nant le logiciel.
Nécessite des res­sources re­la­ti­ve­ment im­por­tantes pour garantir la qualité du produit à la livraison. Ces res­sources sont encore plus im­por­tantes en cas de CD. Elles per­met­tent de livrer le produit à un stade bien antérieur et de le soumettre à de « vé­ri­tables » tests.
Le dé­ve­lop­pe­ment à pro­pre­ment parler est plus efficace, mais est souvent in­ter­rompu par des mises à dis­po­si­tion manuelles. Le dé­ve­lop­pe­ment est continu puisqu’une grande partie du processus de mise à dis­po­si­tion est également au­to­ma­tisé.

Outils de Con­ti­nuous Delivery (Con­ti­nuous Delivery tools) réputés

Dif­fé­rents pro­grammes fa­ci­li­te­ront votre passage à la Con­ti­nuous Delivery. Nous vous en pré­sen­tons quatre.

Jenkins

Jenkins est une ap­pli­ca­tion web per­met­tant l’in­té­gra­tion continue des com­po­santes des logiciels. Basée sur Java, Jenkins fonc­tionne dans n’importe quel conteneur EJB et comprend dif­fé­rents outils de build (Apache Ant, Maven/Gradle, CVS, Sub­ver­sion, Git etc.), mais aussi des processus de test au­to­ma­ti­sés es­sen­tiels pour la Con­ti­nuous Delivery (JUnit, Emma). Des plug-ins fa­cul­ta­tifs ga­ran­tis­sent la com­pa­ti­bi­lité avec d’autres com­pi­la­teurs. L’interface de pro­gram­ma­tion basée sur REST permet de plus à d’autres pro­grammes d’accéder à Jenkins. Jenkins est un programme open source gratuit. Il est prin­ci­pa­le­ment re­com­mandé aux débutants, car l’interface et les fonc­tion­na­li­tés sont conçues de façon très con­vi­viale pour les novices.

Conseil

Découvrez comment fonc­tionne cette ap­pli­ca­tion étape par étape dans notre tutoriel Jenkins.

CircleCI

CircleCI est une ap­pli­ca­tion de Con­ti­nuous In­te­gra­tion, Delivery et De­ploy­ment également basée en ligne. CircleCI travaille en priorité avec GitHub, GitHub En­ter­prise et Bitbucket. Par ailleurs, la pla­te­forme propose de nom­breuses fonc­tion­na­li­tés pratiques, telles qu’une gestion des commandes, une gestion des res­sources, une com­pa­ti­bi­lité avec Docker et tous les langages de pro­gram­ma­tion connus, une mise en cache sécurisée, une analyse des données avec des sta­tis­tiques et des concepts de sécurité complets. En 2017, CircleCI s’est vu décerner la ré­com­pense « Leader in Con­ti­nuous In­te­gra­tion » 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 Foun­da­tion Server

Microsoft Team Foun­da­tion Server (TFS) est un outil de col­la­bo­ra­tion pour les projets logiciels devant être planifiés, créés puis gérés de façon conjointe. TFS est le suc­ces­seur non officiel de Mi­cro­softs Visual Sour­ce­Safe. Afin de permettre un travail col­la­bo­ra­tif sur un projet logiciel, TFS supporte dif­fé­rents processus de dé­ve­lop­pe­ment dont CMMI, le dé­ve­lop­pe­ment logiciel agile et Scrum. Pour faciliter le travail, les pro­grammes Office tels que Word et Excel sont intégrés à TFS pour éviter d’avoir à passer de TFS à un autre programme.

Dif­fé­rentes ca­rac­té­ris­tiques vous per­met­tant de cons­truire un pipeline sont dis­po­nibles pour la Con­ti­nuous In­te­gra­tion, la Con­ti­nuous Delivery et le Con­ti­nuous De­ploy­ment. En principe, TFS divise le processus global en plusieurs sections : contrôle de la version, build, rapports et gestion des uti­li­sa­teurs.

Les équipes cons­ti­tuées de 5 personnes au maximum peuvent utiliser la version Express gratuite ; les équipes plus im­por­tantes devront acquérir la version com­mer­ciale qui coûte environ 6 dollars US par uti­li­sa­teur et par mois. Il vous sera gé­né­ra­le­ment également né­ces­saire d’acquérir une licence de serveur. Vous pouvez faire l’ac­qui­si­tion de TFS sans abon­ne­ment mensuel ; pour cela, vous devrez toutefois contacter un revendeur local. Le prix semble varier de 500 à 700 euros.

Codeship

Codeship est une pla­te­forme SaaS pour la Con­ti­nuous In­te­gra­tion (vs Con­ti­nuous Delivery) dont l’étendue s’adapte aux besoins de l’uti­li­sa­teur. Codeship supporte GitLab, GitHub et Bitbucket. Les fonc­tion­na­li­tés dis­po­nibles dépendent alors des modalités de paiement choisies : dans la version gratuite, Codeship offre un en­vi­ron­ne­ment de CI pré­pa­ra­mé­tré et prend également en charge le workflow ap­pli­cable pour la CI/CD. D’autre part, la version payante propose une mise en cache efficace et la réa­li­sa­tion des tests de builds en parallèle dans des con­te­neurs séparés et pré­con­fi­gu­ré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 uti­li­sa­teurs et les équipes.

Dis­po­nible à 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 plei­ne­ment ce programme. La seconde version payante « Codeship Pro » étend encore la liste des fonc­tion­na­li­tés avec une com­pa­ti­bi­lité Docker, le « contrôle complet » sur l’en­vi­ron­ne­ment de build, des builds locaux et un meilleur contrôle sur le workflow. D’autre part, un plus grand nombre d’outils sont ac­ces­sibles et la Con­ti­nuous In­te­gra­tion vs Con­ti­nuous Delivery est encore plus efficace et trans­pa­rente. Selon le nombre de builds pa­ral­lèles, Codeship Pro coûte environ 70 euros par mois.

Aller au menu principal