FR 3091374 A1 20200703 FR 1874377 A 20181228 Description Titre de l'invention : PROCÉDÉ D'INTÉGRATION CONTINUE, DE DISTRIBUTION CONTINUE, (Cl/CD) ET DE DÉ- PLOIEMENT CONTINU, SUR UNE PLATEFOR1VIE Domaine technique 100011 L'invention concerne le domaine du développement et du déploiement de logiciels sur une plateforme. ÉTAT DE L'ART ANTÉRIEUR 100021 Les équipes de développement se sont adaptées aux cycles de distribution raccourcis en adoptant l'automatisation de leur pipeline de distribution de logiciels. La plupart des équipes disposent de processus automatisés pour contrôler le code et déployer de nouveaux environnements. 100031 L'intégration continue se concentre sur la réunion des interventions de développeurs individuels dans un référentiel, souvent plusieurs fois par jour, le but principal étant de permettre la détection précoce des bogues d'intégration, ce qui devrait se traduire par une plus forte cohésion et une plus grande collaboration au développement. 100041 L'objectif de la distribution continue est de minimiser les points de friction qui sont inhérents aux processus de déploiement ou de publication (déploiement). Généralement, la mise en oeuvre implique l'automatisation de chacune des étapes de construction des déploiements de sorte qu'une publication (déploiement) sûre du code puisse être réalisée - idéalement - à tout moment dans le temps. 100051 Le déploiement continu est un degré plus élevé de l'automatisation, où une construction/un déploiement se produit automatiquement dès qu'un changement important est apporté au code. Chacun de ces stades fait partie d'un pipeline de distribution. [0006] Il y a également un nombre accru de nouveaux outils d'automatisation pour aider avec le pipeline Cl/CD. Ces outils s'intègrent habituellement avec des outils variés pour développeurs, comportant des systèmes de référentiel de code comme GitHub et des systèmes de suivi des bogues comme Jira. [0007] Concoursc est un outil Cl/CD de code source libre, construit sur une mécanique simple des ressources, tâches et travaux. [0008] Le brevet américain US10120670B1 décrit un procédé de déploiement d'une ap- plication, le procédé comprenant : la création, par un processeur, d'un conteneur virtuel comportant au moins un programme qui est génériquement exécutable dans une pluralité d'environnements différents d'intégration et de distribution continues (Cl/CD), la création comprenant : 2 l'incorporation d'au moins un script de stade dans l'au moins un programme, l'au moins un script de stade définissant un flux pour l'au moins un programme, et l'incorporation d'au moins une banque d'utilitaires dans l'au moins un programme, l'au moins une banque d'utilitaires comportant des instructions pour au moins une tâche d'application générique, où l'au moins un script de stade ingère au moins une partie de l'au moins une banque d'utilitaires pendant au moins une étape dans le flux de l'au moins un programme et ingère du code additionnel en dehors de l'au moins une banque d'utilitaires pendant au moins une étape dans le flux de l'au moins un programme ; la création, par un processeur, d'une définition de pipeline séparée d'une définition de pipeline générique pour chacun de la pluralité d'environnements différents Cl/CD, chaque définition de pipeline indiquant l'environnement Cl/CD pour lequel elle est créée et étant configurée pour fonctionner uniquement dans l'environnement Cl/CD pour lequel elle est créée, et chaque définition de pipeline étant configurée pour amener l'environnement Cl/CD pour lequel elle est créée à exécuter l'au moins un programme ; et le déploiement, par le processeur, d'au moins l'une des définitions de pipeline avec le conteneur virtuel dans l'environnement Cl/CD pour lequel l'au moins une des définitions dc pipeline est créée, permettant ainsi d'exécuter l'au moins un programme à l'intérieur de l'environnement Cl/CD pour lequel l'au moins une des définitions de pipeline est créée, où la transition d'un pipeline depuis l'environnement Cl/CD pour lequel l'au moins une des définitions de pipeline est créée vers un autre environnement Cl/CD comporte la personnalisation d'uniquement un script de construction générique pour l'autre environnement Cl/CD. [0009] Cette solution ne prend pas en compte le fait qu'en général, une équipe intervient sur lesdits environnements d'intégration et de distribution (Cl/CD). DISCUSSION DE L'INVENTION [0010] La présente invention a donc pour objet de proposer des procédés d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu, sur une plateforme, en donnant la possibilité de surmonter au moins une partie des inconvénients de l'art antérieur. [0011] La présente invention se rapporte à un procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu, sur une platetbrme exécutant un logiciel OIT, un système de commande de version pour suivre les changements dans les fichiers informatiques et un référentiel pour coordonner les interventions sur ces fichiers entre plusieurs personnes, et GitHub, un service d'hébergement en ligne pour commander la version utilisant Git, ledit service utilisant un pipeline Concourse dont le but est de déclencher et d'exécuter automatiquement les travaux (étapes) dès qu'un dé- 3 veloppeur provoque un changement dans un référentiel Git, procédé CI dans lequel les développeurs intègrent fréquemment leur code dans un référentiel commun mémorisé dans un support lisible par machine chaque fois que le code est entré, le système lance le processus de compilation, effectue des tests unitaires et d'autres contrôles de qualité si besoin et dans lequel le procédé CD exécute un ensemble progressif de suites de tests à l'encontre de chaque processus de construction ou de développement et alerte l'équipe de développement en cas de défaillance, qui le corrige ensuite. [0012] Selon un mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu, dans lequel un processus de construction comprend des déploiements de différents composants à l'intérieur de la plateforme en tant que service (PaaS), au moins : un composant de configuration définissant un pipeline Concourse par un fichier pipeline.yml mémorisé dans un support lisible par machine, ledit fichier définissant les travaux à exécuter ; et un composant de déploiement mettant en oeuvre un processus de déploiement en 3 étapes (Dey, Prc-Prod, Prod) utilisant une interpolation depuis BOSH 2.0 pour externaliser les variables de configuration à l'intérieur du déploiement de la plateforme en tant que service (PaaS) pendant lequel : [0013] Selon un autre mode de réalisation, les fichiers de déploiement de la plateforme en tant que service (PaaS) sont convertis en formats modélisés avec des espaces réservés pour des variables de configuration ; ces variables sont ensuite externalisées dans un fichier de variables dev_env.yml pour l'environnement DEV, pre-prod_env.yml pour l'environnement PRE-PROD et un fichier prod.env.yrn1 pour l'environnement PROD. [0014] Selon un autre mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu de l'invention, dans lequel pendant la configuration, Pipeline Concourse utilise un fichier resources.yml pour définir la ressource à surveiller, dans ce cas, l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : _REL_, et le fichier credentials.yrnl, est constitué d'une accréditation utilisateur de référentiel GitHub et d'un type d'environnement comme DEV, PRE-PROD ou PROD. [0015] Selon un autre mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu de l'invention, dans lequel Pipeline Concourse est un fichier Makefile fonctionnant en continu, de niveau supérieur, distribué, de logiciel MAKE exécuté sur une machine numérique. [0016] Selon un autre mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu de l'invention, dans lequel pendant le développement, le Pipeline Concourse est défini par un fichier pipeline.yml qui définit les travaux à exécuter : Le pipeline utilise un fichier resources.yml pour définir la ressource à surveiller,dans ce cas le fichier resources.yml définit : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : DEV REL #. Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif DEV REL #. [0017] Selon un autre mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu de l'invention, dans lequel pour paramétrer le pipeline d'environnement Preprod où un fichier credentials.yml est utilisé avec des variables ENV paramétrécs sur PRE-PROD ; le pipeline Concourse est défini par un fichier prcprod pipel ine.yrn1 qui définit les travaux à exécuter. Le pipeline utilise un fichier preprod resources.yml pour définir la ressource à surveiller, dans ce cas : l'URL GitHub en tant que URL de référentiel la branche : MASTER et la balise : REL #. Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif PRE_PROD_REL_# Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans preprod_env.yrn1 pour l'environnement Preprod. Les adresses IP, les certificats, les mots de passe utilisés dans les déploiements seront stockés dans un fichier preprod_env.yml. Le fichier preprod_env.yml est utilisé pour des déploiements supplémentaires. Pour un déploiement PreProd Global BOSH, BOSH 2 analysera ces variables en utilisant un processus d'interpolation, et les variables seront remplacées dans référentiel de déploiement modélisé et le travail de Concourse déploiera Global BOSH. Comme montré dans le schéma, le pipeline est un mélange de travaux en parallèle et en série pour des déploiements, Proto BOSH déploie Proto Shield et PreProd Global BOSH et d'autres déploiements requis. PreProd Global BOSH déploiera PreProd Client BOSH et PreProd Global Shield et PreProd Client BOSH déploiera Preprod Client Shield, Preprod ACF et d'autres services. Le pipeline de Preprod reste à l'état de pause, PAUSED. Et il n'est plus en pause, UNPAUSED, uniquement pendant un cycle de test de publication (déploiement). [0018] Selon un autre mode de réalisation, le procédé d'intégration continue, de distribution continue, (Cl/CD) et de déploiement continu de l'invention dans lequel, pour pa- ramétrer le pipeline d'environnement PROD où un fichier credentials.yml est utilisé avec des variables ENV paramétrées sur PROD ; Le Pipeline Concourse est défini par un fichier prod pipeline.yml qui définit les travaux à exécuter. Le pipeline utilise un fichier prod resources.yml pour définir la ressource à surveiller, clans ce cas : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : PROD REL #. Pipeline Concoursc est déclenché lorsque la branche définie est balisée avec le motif PROD REL #. Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans prod env.yrn1 pour l'environnement PROD, ce fichier est utilisé pour des déploiements supplémentaires. Les adresses IP, les certificats, les mots de passe utilisés dans les déploiements seront stockés dans le fichier prod env.yml. Pour un déploiement Prod Global BOSH, BOSH 2 analysera ces variables en utilisant une interpolation, et les variables seront remplacées dans un référentiel de déploiement modélisé. Et le travail de Concoursc déploiera Global BOSH. Comme montré dans le schéma, le pipeline est un mélange de travaux en parallèle et en série pour des déploiements. Prato BOSH déploie Prato Shicld et Prod Global BOSH et d'autres déploiements requis. Prod Global BOSH déploiera Prod Client BOSH et Prod Global Shicld et Prod Client BOSH déploiera Prod Client Shicld, Prod CF et d'autres services. Le pipeline de Prod et tous les travaux dans le pipeline de Prod restent à l'état de pause, PAUSED, pour ne plus être en pause, UNPAUSED, uniquement le jour de la publication (déploiement). DESCRIPTION DE L'INVENTION [0019] De nombreuses combinaisons peuvent être envisagées sans s'écarter de la portée de l'invention ; un homme de l'art en choisira une en fonction de contraintes économiques, ergonomiques, dimensionnelles ou autres qu'il aura à respecter. [0020] Dans la description qui suit, aux fins d'explication, des détails spécifiques sont révélés afin de fournir une compréhension approfondie des modes de réalisation de l'invention. Cependant, il sera évident que les modes de réalisation variés peuvent être pratiqués sans ces détails spécifiques. Les figures et la description ne se veulent pas restrictives. [0021] La description subséquente fournit uniquement des modes de réalisation exemplaires, et ne vise pas à limiter la portée, l'applicabilité, ou la configuration de l'invention. Au contraire, la description subséquente des modes de réalisation exemplaires fournira à l'homme de l'art une description habilitante pour mettre en oeuvre un mode de réa- 6 lisation exemplaire. Il est entendu que des changements variés peuvent être apportés à la fonction et à l'agencement des éléments sans s'écarter de l'esprit et de la portée de l'invention tels qu'ils sont révélés dans le présent document. [0022] Des détails spécifiques sont donnés dans la description qui suit pour fournir une com- préhension approfondie des modes de réalisation. Cependant, on comprendra par une compétence ordinaire dans l'art que les modes de réalisation peuvent être pratiqués sans ces détails spécifiques. Par exemple, les circuits, systèmes, réseaux, processus et autres composants peuvent être montrés en tant que composants sous la forme de schémas fonctionnels afin de ne pas occulter les modes de réalisation par des détails superflus. Dans d'autres circonstances, des circuits, processus, algorithmes, structures, et techniques bien connus peuvent être montrés sans détails superflus afin d'éviter d'occulter les modes de réalisation. [0023] De plus, il est à noter que des modes de réalisation individuels peuvent être décrits en tant que processus qui est présenté en tant qu'organigramme, un schéma de flux, un schéma de flux de données, un schéma de structure, ou des schémas fonctionnels. Bien qu'un organigramme puisse décrire les opérations comme un processus séquentiel, nombre de ces opérations peuvent être réalisées en parallèle ou en même temps. Par ailleurs, l'ordre des opérations peut être réagencé. Un processus prend fin lorsque ses opérations sont terminées, mais peut compter des étapes additionnelles qui ne sont pas incluses dans une figure. Un processus peut correspondre à un procédé, une fonction, une procédure, une sous-routine, un sous-programme, etc. Lorsqu'un processus correspond à une fonction, sa fin peut correspondre à un retour de la fonction à la fonction d'appel ou à la fonction principale. [0024] Le terme « support de stockage lisible par machine » ou « support de stockage lisible par ordinateur », signifie, sans s'y limiter, des dispositifs de stockage portables ou non portables, des dispositifs de stockage optiques, et d'autres supports variés capables de stocker, contenir, ou transporter une/des instruction(s) et/ou des données. Un support lisible par machine peut comporter un support non transitoire où des données peuvent être stockées et qui ne comporte pas d'ondes porteuses et/ou de signaux électroniques transitoires se propageant sans fil ou sur des connexions filaires. Des exemples de supports non transitoires peuvent comporter, mais sans s'y limiter, un disque ou une bande magnétique, des supports de stockage optiques tels qu'un disque compact (CD) ou un disque numérique polyvalent (DVD), une mémoire flash, une mémoire ou des dispositifs de mémoire. Un produit de programme informatique peut comporter du code et/ou des instructions exécutables par machine qui peuvent représenter une procédure, une fonction, un sous-programme, un programme, une routine, une sous-routine, un module, un progiciel, une classe, ou toute combinaison d'instructions, de structures de données, ou d'instructions de programme. Un segment de code peut 7 être couplé à un autre segment de code ou à un circuit matériel en passant et/ou en recevant des informations, des données, des arguments, des paramètres ou du contenu mémoire. Les informations, arguments, paramètres, données, etc. peuvent être passés, communiqués, ou transmis via tout moyen approprié comportant le partage de mémoire, le passage de messages, le passage de jetons, la transmission sur le réseau, etc. [0025] [fig.1] La figure illustre un mode de réalisation d'une partie du processus de la présente invention, où les fichiers, à titre d'exemple, des référentiels peuvent être modélisés et interpolés si nécessaire avant utilisation dans les autres étapes de l'invention décrites ci-dessous. [0026] [fig.2] La figure 2 montre les différentes étapes suivies par BOSH API pendant le dé- veloppement et le déploiement d'une application. [0027] Pipeline Concoursc est un fichier Makefilc fonctionnant en continu, de niveau supérieur, distribué. Le but de Pipeline Concoursc est de déclencher et d'exécuter automatiquement les travaux (étapes) dès qu'un développeur provoque un changement dans un référentiel Oit. [0028] Les ressources de Concoursc sont des dépendances externes utilisées à l' intérieur de Concours° pour y surveiller les changements, y récupérer des fichiers et y stocker des fichiers. [0029] Les travaux de Concourse comprendnt les étapes à exécuter lorsqu'un pipeline est déclenché. [0030] Processus [0031] Intégration continue [0032] Le but du procédé CI est de faire du processus d'intégration une tâche de déve- loppement simple, pouvant être répétée facilement, et tous les jours pour réduire les coûts globaux de construction et révéler précocement les défauts dans le cycle. Il amène les développeurs à mener l'intégration plus tôt et plus fréquemment, plutôt que d'un seul coup à la fin. Étant donné que dans la pratique, un développeur découvrira souvent des défis liés à l'intégration entre les nouveaux codes et ceux déjà existant, uniquement au moment de l'intégration, si celle-ci est réalisée précocement et souvent, les conflits seront plus faciles à identifier et moins coûteux à résoudre. [0033] Avec le procédé CI, les développeurs intègrent fréquemment leur code dans un ré- férentiel commun. Plutôt que de construire des caractéristiques de manière isolée et de soumettre chacune d'entre elles à la fin du cycle, ils construisent en continu des produits d'intervention de logiciel plusieurs fois, n'importe quel jour. Chaque fois que le code est entré, le système lance le processus de compilation, effectue des tests unitaires et d'autres contrôles de qualité si besoin. [0034] Le procédé CI s'appuie fortement sur les suites de tests et sur une exécution au- 8 tomatisée des tests. Lorsqu'il est effectué correctement, il permet aux développeurs de réaliser des constructions fréquemment et de manière répétée, et de traiter les bogues précocement dans le cycle de vie. [0035] Distribution continue [0036] Le but principal du procédé CD est de produire un logiciel dans des cycles courts de sorte que de nouvelles caractéristiques et changements puissent être libérés rapidement, de manière sûre, et fiable à tout moment. Étant donné que le procédé CD implique d'automatiser chacune des étapes pour la distribution de la construction, il minimise les points de friction qui sont inhérents aux processus de déploiement ou de publication (déploiement) et permet de s'assurer qu'une publication (déploiement) sûre du code puisse être réalisée à tout moment. [0037] Le procédé CD exécute un ensemble progressif de suites de tests à l'encontre de chaque construction et alerte l'équipe de développement en cas de défaillance, qui le corrige ensuite. Dans des situations où il n'y a pas de problèmes, le procédé CD conduit les tests de manière séquentielle. Le résultat final est une construction qui peut être déployé et vérifiée dans un environnement de production réel. [0038] Étant donné que le procédé CD vise à construire, tester, et libérer le logiciel ra- pidement et fréquemment, il dépend d'un système automatisé qui aide l'équipe de développement à automatiser les tests et à déployer les processus. Ceci permet de s'assurer que le code est toujours dans un état déployable. [0039] Processus de construction [0040] Un processus de construction consiste à déployer différents composants à l'intérieur de la platefonne en tant que service (PaaS). [0041] Configuration : [0042] Le pipeline Concourse est défini par un fichier pipeline.yml qui définit les travaux à exécuter. [0043] Le pipeline utilise un fichier resources.yml pour définir la ressource à surveiller, dans ce cas, l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : _REL_# Pipeline Concourse est déclenché lorsque la branche définie est balisée pendant le processus de la figure 1 avec le motif _REL_# GitHub est un service d'hébergement en ligne pour commander la version utilisant Git. Il est surtout utilisé pour le code informatique. Il offre toutes les fonctionnalités de Git de commande des versions diffusées et de gestion du code source (SCM) ainsi que l'ajout de ses propres caractéristiques. Il fournit une commande d'accès et plusieurs caractéristiques de collaboration comme la poursuite des bogues, les demandes de caractéristiques, la gestion des tâches et des wikis pour chaque projet. Git est un système de commande de version pour suivre les changements dans les fichiers informatiques et coordonner les interventions sur ces fichiers entre plusieurs personnes. Il est princi- 9 paiement utilisé pour la gestion de code-source dans logiciel développement, mais il peut être utilisé pour suivre les changements dans n'importe quel ensemble de fichiers. [0044] Le fichier credentials.ymi est constitué d'une accréditation utilisateur de référentiel GitHub et d'un type d'environnement comme DEV, PRE-PROD ou PROD. [0045] Processus de Déploiement [0046] Le processus de déploiement utilise l'interpolation depuis BOSH 2.0 pour ex- ternaliser les variables de configuration à l'intérieur du déploiement de la plateforme en tant que service (PaaS). [0047] Les fichiers de déploiement de platcforrne en tant que service (PaaS) sont convertis en formats modélisés avec des espaces réservés pour des variables de configuration [0048] Ces variables sont ensuite externalisécs dans un fichier de variables dev env.ymi pour l'environnement DENT, prc-prod env.yml pour l'environnement PRE-PROD et ainsi de suite. [0049] Différents fichiers de variables sont créés pour différents environnements pour s'assurer que les configurations restent séparées. [0050] L'interpolation BOSH 2.0 est utilisée pour fusionner le modèle avec les variables spécifiques à l'environnement pour générer un fichier de déploiement final. Ce fichier est utilisé pour des déploiements. [0051] Déploiement dans un environnent existant [0052] Environnements [0053] Environnent DEV [0054] Le déploiement Proto BOSH est réalisé manuellement. Le pipeline de l'environnement DEV utilise un fichier credentials.yml où une variable ENV est paramétrée sur DEV par le processus représenté dans la figure I. Le pipeline Concourse est défini par un fichier pipeline.yml qui définit les travaux à exécuter. Le pipeline utilise un fichier resources.yml pour définir la ressource à surveiller, dans ce cas les ressources suivantes sont surveillées : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : DEV_REL_#. Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif DEV_REL_# À la fin de processus de figure 1. Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans un fichier dev_env.yrn1 pour l'environnement DEV, ce fichier est utilisé pour des déploiements supplémentaires. Ex., les adresses IP, les certificats, les mots de passe utilisées dans les déploiements seront stockés dans le fichier dev_env.yml. Pour un déploiement Dey Global BOSH, BOSH2 analysera ces variables en utilisant une interpolation et les variables seront remplacées dans référentiel de déploiement modélisé. Et le travail de Concourse déploiera Global BOSH. Comme montré dans le schéma, le pipeline est un mélange de travaux en parallèle et en série pour des déploiements. Ex. Prote BOSH déploie Prote Shield et Dey Global BOSH et d'autres déploiements requis. Dev Global BOSH déploiera DEV Client BOSH et DEV Global Shield et DEV Client BOSH déploiera DEV Client Shield, DEV ACE et d'autres services. Une fois ACE déployé et sa publication (déploiement) testée avec succès, la branche GitHub peut être balisée un numéro de publication (déploiement) final. [0055] Environnement Pre-Prod [0056] L'environnement Pre-Prod est créée de nouveau à chaque fois. Le déploiement Preto BOSH déjà existant est utilisé pour des déploiements dans l'environnement PRE-PROD. Pour paramétrer le pipeline d'environnement Preprod où un fichier credentials.yrn1 est utilisé avec des variables ENV paramétrécs sur PRE-PROD. Le pipeline Concourse est défini par un fichier preprod pipeline.yml qui définit les travaux à exécuter. Le pipeline utilise un fichier preprod resources.yml pour définir la ressource à surveiller, dans ce cas : l'URL GitHub en tant que URL de référentiel la branche : MASTER et la balise : REL_# Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif PRE_PROD_REL_# Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans preprod_env.yml pour l'environnement Preprod. Les adresses IP, les certificats, les mots de passe utilisés dans les déploiements seront stockés dans le fichier preprod_env.yml file. Le fichier preprod_env.yml est utilisé pour des déploiements supplémentaires. Pour un déploiement PreProd Global BOSH, BOSH 2 analysera ces variables en utilisant le processus d'interpolation de la figure 1 et les variables seront remplacées dans référentiel de déploiement modélisé et le travail de Concourse déploiera Global BOSH. Comme montré dans le schéma, le pipeline est un mélange de travaux en parallèle et en série pour des déploiements, Proto BOSH déploie Proto Shield et PreProd Global BOSH et d'autres déploiements requis. PreProd Global BOSH déploiera PreProd Client BOSH et PreProd Global Shield et PreProd Client BOSH déploiera Preprod Client Shield, Preprod ACF et d'autres services. 11 Le pipeline de Preprod reste à l'état de pause, PAUSED. Et il n'est plus en pause, UNPAUSED, uniquement pendant un cycle de test de publication (déploiement). [0057] Environnement de production [0058] Le déploiement Preto BOSH déjà existant est utilisé pour des déploiements dans l'environnement PROD. Pour paramétrer le pipeline d'environnement PROD où un fichier credentials.yml est utilisé avec des variables ENV paramétrées sur PROD. Le pipeline Concours° est défini par un fichier prod pipeline.yml qui définit les travaux à exécuter. Le pipeline utilise un fichier prod resources.yml pour définir la ressource à surveiller, dans ce cas : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : PROD REL #. Pipeline Concoursc est déclenché lorsque la branche définie est balisée avec le motif PROD REL #. Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans prod env.yrn1 pour l'environnement PROD, ce fichier est utilisé pour des déploiements supplémentaires. Les adresses IP, les certificats, les mots de passe utilisés dans les déploiements seront stockés dans le fichier prod env.yml. Pour un déploiement Prod Global BOSH, BOSH 2 analysera ces variables en utilisant une interpolation et les variables seront remplacées dans un référentiel de déploiement modélisé. Et le travail de Concourse déploiera Global BOSH. Comme montré dans le schéma, le pipeline est un mélange de travaux en parallèle et en série pour des déploiements. Proto BOSH déploie Proto Shield et Prod Global BOSH et d'autres déploiements requis. Prod Global BOSH déploiera Prod Client BOSH et Prod Global Shield et Prod Client BOSH déploiera Prod Client Shield Prod CF et d'autres services. Le pipeline de Prod et tous les travaux dans le pipeline de Prod restent à l'état de pause, PAUSED, pour ne plus être en pause, UNPAUSED, uniquement le jour de la publication (déploiement). [0059] Ayant décrit et illustré les principes de l'invention en se référant à des modes de réa- lisation variés, il sera reconnu que les modes de réalisation variés peuvent être modifiés selon des agencements et détails sans s'écarter de ces principes. Il sera apprécié que les différents concepts et aspects de l'invention décrits ci-dessus puissent être mis en oeuvre, par exemple, en utilisant un(e) ou plusieurs processeur(s), module(s), instruction(s) exécutable(s) par machine, ordinateur(s) et/ou serveur(s). Il est entendu que le concept et les aspects de l'invention décrits dans le présent 1-> document ne sont ni liés ni limités à aucun type particulier d'environnement informatique, sauf indication contraire. Des types variés d'environnements informatiques spécialisés peuvent être utilisés avec ou réaliser des opérations suivant les enseignements décrits dans le présent document. Des éléments de modes de réalisation montrés dans logiciel peuvent être mis en oeuvre dans le matériel et vice versa. [0060] Un ou plusieurs dispositif(s), processeur(s) ou dispositif(s) de traitement peut/ peuvent être configuré(s) pour mener la/les fonction(s) de chacun de éléments et modules de l'agencement structurel décrit dans le présent document. Par exemple, le ou les plusieurs dispositif(s), processeur(s) ou dispositif(s) de traitement peut/peuvent être configuré(s) pour exécuter une ou plusieurs séquence(s) d'une ou de plusieurs instruction(s) exécutable(s) par machine contenue(s) dans une mémoire principale pour mettre en oeuvre le/les procédé(s) ou fonction(s) décrit(es) dans le présent document. L'exécution des séquences d'instructions contenues dans une mémoire principale amène les processeurs à réaliser au moins quelques-unes des étapes ou fonction(s) du processus des éléments décrits dans le présent document. Un ou plusieurs processcur(s) dans un agencement à traitement multiple peut, de plus, être employé pour exécuter les séquences d'instructions contenues dans une mémoire principale ou un support lisible par ordinateur. Dans des modes de réalisation alternatifs, un circuit câblé peut être utilisé à la place de ou en combination avec des instructions de logiciel. Ainsi, les modes de réalisation ne sont limités à aucune combination spécifique de circuit câblé et de logiciels. [0061] 11 sera facile de comprendre à la lecture de la présente demande que les particularités de la présente invention peuvent, telles que généralement décrites et illustrées dans les figures, être agencées et conçues selon une grande variété de configurations différentes. Ainsi, la desmiption de la présente invention et les figures qui y sont liées ne sont pas fournies en vue de limiter la portée de l'invention mais simplement pour illustrer des modes de réalisation choisis. [0062] Un homme de l'art comprendra que les caractéristiques techniques d'un mode de réa- lisation donné peuvent en effet être combinées avec les caractéristiques d'un autre mode de réalisation à moins que le contraire ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles. En outre, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de de mode de réalisation à moins que le contraire ne soit explicitement mentionné. [0063] 11 devrait être évident pour les personnes compétentes dans le domaine de l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans s'écarter du domaine défini par la portée de l'invention, ces modes de réalisation devraient être considérés comme une illustration et l'invention ne devrait 13 pas âtre limitée aux détails donnés ci-dessus. 14 [Revendication I] [Revendication 2] REVENDICATIONSProcédé d'intégration, de distribution et de déploiement continus de logiciels informatiques, sur une plateforme exécutant un logiciel de type OIT, via un système de commande de version pour suivre les changements dans les fichiers informatiques et un référentiel OIT pour coordonner les interventions sur ces fichiers entre plusieurs personnes, grâce à un service d'hébergement en ligne, de type GitHub, utilisant un pipeline de type Concourse, ledit procédé étant caractérisé en ce que, à chaque intervention d'un développeur provoquant un changement dans ledit référentiel Git, les étapes suivantes sont mises en oeuvre : - exécution du processus de compilation du code modifié par ledit développeur dans ledit référentiel ; - exécution de tests unitaires, de contrôles de qualité, et d'un ensemble progressif de suites de tests à l'encontre de chaque processus de construction ou de développement et alerte l'équipe de développement en cas de défaillance. Procédé d'intégration, de distributionet de déploiement continus selon la revendication 1, dans lequel un processus de construction comprend des déploiements de différents composants à l'intérieur de la plateforme en tant que service (PaaS), au moins : un composant de configuration définissant un Pipeline Concourse par un fichier pipeline.yml mémorisé dans un support lisible par machine, ledit fichier définissant les travaux à exécuter ; et un composant de déploiement mettant en oeuvre un processus de déploiement en 3 étapes (Dey, Pre-Prod, Prod) utilisant une interpolation depuis BOSH 2.0 pour extemaliser les variables de configuration à l'intérieur du déploiement de la PaaS pendant lequel : les fichiers de déploiement de la PaaS sont convertis en formats modélisés avec des espaces réservés pour des variables de configuration ; ces variables sont ensuite extemalisées dans un fichier de variables dev env.yml pour l'environnement DEV, pre-prod env.yml pour l'environnement PRE-PROD et un fichier prod.env.yml pour l'environnement PROD.3. Procédé d'intégration, de distribution continueet de déploiement continus de l'une des revendications 1 à 2 dans lequel, pendant la configuration, Pipeline Concourse utilise un fichier resources.yml pour définir la ressource à surveiller, dans ce cas, 15 [Revendication 4] [Revendication 5] [Revendication 6] l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : REL , et le fichier credentials.yml est constitué d'une accréditation utilisateur de référentiel GitHub et d'un type d'environnement comme DENT. PRE-PROD ou PROD. Procédé d'intégration, de distribution et de déploiement continus de l'une des revendications 1 à 3 dans lequel Pipeline Concourse est un fichier Makefile fonctionnant en continu, de niveau supérieur, distribué, de logiciel MAKE exécuté sur une machine numérique. Procédé d'intégration, de distribution et de déploiement continus, de l'une des revendications 1 à 4 dans lequel pendant le développement, le Pipeline Concourse est défini par un fichier pipeline.yml qui définit les travaux à exécuter. Le pipeline utilise un fichier resources.yml pour définir la ressource à surveiller, dans ce cas le fichier rcsources.yml définit : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : DEV REL # ; Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif DEV REL #. Procédé d'intégration, de distribution et de déploiement continus, de l'une des revendications 1 à 5 dans lequel, pour paramétrer le pipeline d'environnement Preprod où un fichier credentials.yml est utilisé avec des variables ENV paramétrées sur PRE-PROD ; Le Pipeline Concourse est défini par un fichier preprod_pipeline.yml qui définit les travaux à exécuter ; Le pipeline utilise un fichier preprod_resources.yml pour définir la ressource à surveiller, dans ce cas : l'URL GitHub en tant que URL de référentiel la branche : MASTER et la Balise : REL_# ; Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif PRE_PROD_REL_# ; Une fois que le pipeline est paramétré, les variables de configuration sont stockées dans preprod_env.yml pour l'environnement Preprod ; les adresses IP, les certificats, les mots de passe utilisés dans les déploiements sont stockés dans un fichier preprod_env.yml ; Un fichier preprod_env.yml est utilisé pour des déploiements supplémentaires ; 16 [Revendication 7] Pour un déploiement PreProd Global BOSH, BOSH 2 analyse ces variables en utilisant un processus d'interpolation et les variables sont remplacées dans un référentiel de déploiement modélisé et le travail de Concourse déploie Global BOSH; le pipeline est un mélange de travaux en parallèle et en série pour les déploiements, Prote BOSH déploie Proto Shield et PreProd Global BOSH et d'autres déploiements requis ; PreProd Global BOSH déploie PreProd Client BOSH et PreProd Global Shield et PreProd Client BOSH déploie Preprod Client Shield, Preprod ACF et d'autres services ; Le pipeline de Preprod reste à l'état de pause, PAUSED ; et n'est plus en pause. UNPAUSED, uniquement pendant un cycle de test de déploiement (publication). Procédé d'intégration, de distribution et de déploiement continus, de l'une des revendications 1 à 6 dans lequel, pour régler le pipeline d'environnement PROD où un fichier credentials.yml est utilisé avec des variables ENV paramétrécs sur PROD ; Le Pipeline Concourse est défini par prod file pipeline.yml qui définit les travaux à exécuter ; le pipeline utilise un fichier prod resources.yml pour définir la ressource à surveiller, dans ce cas : l'URL GitHub en tant que URL de référentiel, la branche : MASTER et la balise : PROD_REL_# ; Pipeline Concourse est déclenché lorsque la branche définie est balisée avec le motif PROD_REL_# ; Une fois que le pipeline est paramètre-, les variables de configuration sont stockées dans prod_env.yml pour l'environnement PROD, ce fichier est utilisé pour des déploiements supplémentaires les adresses IP, les certificats, les mots de passe utilisés dans les déploiements sont stockés dans un fichier prod_env.yml ; Pour un déploiement Prod Global BOSH, BOSH 2 analyse ces variables en utilisant une interpolation, et les variables seront remplacées dans un référentiel de déploiement modélisé ; et travail de Concourse déploie Global BOSH ; le pipeline est un mélange de travaux en parallèle et en série pour des déploiements ; Proto BOSH déploie Prou) Shield et Prod Global BOSH et d'autres déploiements requis ; Prod Global BOSH déploie Prod Client BOSH et Prod Global Shield et Prod Client BOSH déploie Prod Client Shield Prod CF et d'autres services ; 17 Le pipeline de Prod et tous les travaux dans le pipeline de Prod restent à l'état de pause, PAUSED, pour ne plus être en pause, UNPAUSED, uniquement le jour de la publication (déploiement).