Con­ti­nuous In­te­gra­tion vs. Con­ti­nuous Delivery vs. Con­ti­nuous De­ploy­ment : aperçu des modèles de dé­ve­lop­pe­ment logiciel

Les processus de dé­ve­lop­pe­ment logiciel sont coûteux, en par­ti­cu­lier lorsque l’in­té­gra­tion du code fini pose des problèmes dans le logiciel existant. Les approches modernes de Con­ti­nuous In­te­gra­tion, Delivery et De­ploy­ment (in­té­gra­tion, livraison et dé­ploie­ment continus) per­met­tent d’y remédier. Celles-ci misent sur des va­li­da­tions multiples du code durant son dé­ve­lop­pe­ment. De plus, le fait de tra­vail­ler en plusieurs petites phases de dé­ve­lop­pe­ment permet de fournir au client des pro­to­types du produit souhaité. Celui-ci peut ainsi faire des ajus­te­ments tout au long du dé­ve­lop­pe­ment et voir si le logiciel prend la forme souhaitée.

Les modèles modernes de dé­ve­lop­pe­ment logiciel trouvent tous leur origine dans le concept de dé­ve­lop­pe­ment logiciel agile. Il s’agit d’une approche qui vise non seulement à accélérer le dé­ve­lop­pe­ment de logiciels, mais aussi à le rendre plus trans­pa­rent. L’objectif de la méthode de travail agile est de dé­ve­lop­per des logiciels dont le client a réel­le­ment besoin. Grâce à des pro­to­types mis à dis­po­si­tion à chaque phase du dé­ve­lop­pe­ment, le client peut vérifier si le logiciel fait vraiment ce qu’il doit faire et s’il est com­pa­tible avec les logiciels existants. Les méthodes agiles per­met­tent également de prendre en compte les souhaits des clients qui n’ap­pa­rais­sent qu’au cours du processus de dé­ve­lop­pe­ment.

La tendance au dé­ve­lop­pe­ment agile se poursuit également dans les cultures d’en­tre­prise. Il existe plusieurs approches qui visent à accélérer les processus de dé­ve­lop­pe­ment au sein de l’en­tre­prise. L’une d’entre elles est DevOps. Le terme se compose des mots « De­ve­lop­ment » (dé­ve­lop­pe­ment) et « Ope­ra­tions » (opé­ra­tions). L’objectif de cette culture d’en­tre­prise est que les équipes de dé­ve­lop­pe­ment pro­pre­ment dites col­la­bo­rent avec les équipes or­ga­ni­sa­tion­nelles d’une en­tre­prise pendant toute la phase de dé­ve­lop­pe­ment du logiciel et au-delà. Cela permet d’éviter dès le départ les problèmes d’in­té­gra­tion des logiciels. La main­te­nance et la mise à dis­po­si­tion des pro­grammes terminés sont également fa­ci­li­tées. En plus du dé­ve­lop­pe­ment continu, les re­pré­sen­tants de DevOps misent sur l’in­té­gra­tion et le dé­ploie­ment continus.

Dans le concept de Con­ti­nuous In­te­gra­tion, l’objectif est d’intégrer le plus ra­pi­de­ment possible les mo­di­fi­ca­tions apportées à un projet logiciel dans l’ensemble du logiciel. Le code est donc mis à jour quo­ti­dien­ne­ment par les dé­ve­lop­peurs. Pour ce faire, on utilise non seulement dif­fé­rents outils d’in­té­gra­tion continue, mais surtout des systèmes de contrôle de version comme GitHub. Ceux-ci per­met­tent d’en­re­gis­trer des copies locales de l’ensemble du projet sur son propre or­di­na­teur. Les pro­gram­meurs peuvent apporter des mo­di­fi­ca­tions au code et les té­lé­char­ger dans le système de contrôle de version. Ensuite, l’ensemble du programme peut être soumis à dif­fé­rents tests. De cette manière, les problèmes d’in­té­gra­tion peuvent être évités à l’avance.

Le concept de Con­ti­nuous Delivery va encore plus loin : non seulement le code est mis à jour quo­ti­dien­ne­ment et chaque mo­di­fi­ca­tion est intégrée le plus ra­pi­de­ment possible, mais un prototype est en outre mis à la dis­po­si­tion du client le plus tôt possible. La com­pa­rai­son entre Con­ti­nuous In­te­gra­tion et Con­ti­nuous Delivery montre que la livraison continue se concentre avant tout sur le feedback du client. Grâce à la livraison précoce d’un code partiel prêt à l’emploi, il est possible de tester le logiciel système dans son en­vi­ron­ne­ment réel. Tout ce qui ne plaît pas encore au client peut être adapté dans la suite du processus de dé­ve­lop­pe­ment. Si le code partiel plaît au client, il est ensuite déployé ma­nuel­le­ment.

Le Con­ti­nuous De­ploy­ment suit une approche similaire, mais encore plus étendue. Cette méthode utilise des tests au­to­ma­ti­sés qui sont di­rec­te­ment intégrés dans le processus de dé­ve­lop­pe­ment. La com­pa­rai­son entre Con­ti­nuous Delivery et Con­ti­nuous De­ploy­ment montre clai­re­ment qu’avec le dé­ploie­ment continu, il n’y a pas de délai entre le moment du test et celui de la sortie du code. Grâce aux cadres de test détaillés, les dé­ve­lop­peurs n’ont même plus besoin d’attendre le feedback du client, mais peuvent mettre à dis­po­si­tion leur code partiel di­rec­te­ment de manière au­to­ma­ti­sée après le dé­ve­lop­pe­ment.

Le modèle de dé­ve­lop­pe­ment le mieux adapté dépend en­tiè­re­ment des exigences spé­ci­fiques du projet. Dans l’ensemble, les trois modèles offrent toutefois le plus d’avantages lorsque le client et les dé­ve­lop­peurs peuvent tra­vail­ler en étroite col­la­bo­ra­tion.

Le dé­ploie­ment continu est certes coûteux en raison des pro­cé­dures de test complexes, mais il permet aux clients de constater les amé­lio­ra­tions quo­ti­diennes du logiciel. En outre, le processus de dé­ve­lop­pe­ment est accéléré car il n’est in­ter­rompu à aucun moment. Il est donc souvent possible d’éco­no­mi­ser les coûts sup­plé­men­taires liés aux cadres de test. Dans le cas de la livraison continue, le client dispose encore d’une grande marge de manœuvre, de sorte que les exigences peuvent être spé­ci­fiées ul­té­rieu­re­ment sans in­con­vé­nient. Les petites mo­di­fi­ca­tions du code sont également faciles à réaliser.

La com­pa­rai­son Con­ti­nuous In­te­gra­tion vs. Con­ti­nuous Delivery montre que la livraison continue renonce to­ta­le­ment à la pu­bli­ca­tion in­ter­mé­diaire du code. Ce processus de travail vaut donc surtout la peine pour les petits projets pour lesquels une mise à jour per­ma­nente n’est pas per­ti­nente, voire constitue un obstacle.