Orange
de Spring à Spring Boot
Spring Boot et la démarche DevOps
septembre 2020
industrialiser ses développements Java
sommaire
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – enjeux du DevOps
– du build au déploiement continu – les niveaux de Cloud
– monolithe ou microservices ? – twelve-factor apps
enjeux du DevOps
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
enjeux du DevOps
Le DevOps a pour avantages :
Comment mettre en place le DevOps ?
Il est nécessaire d'automatiser (donc d'outiller) au maximum les différentes tâches, qui vont du développement jusqu'au déploiement sur une plateforme.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – de réduire le Time To Market :
- délai entre l'idée (fonctionnalité, correction de bug) et sa mise à disposition pour le client
- arrivée sur le marché plus rapide (adoption par les clients de nos produits plutôt que ceux des concurrents) - réduction du stock de code qui végète avant qu'il soit mis en production
– d'apprendre des retours clients et des métriques : - rectifier le tir si besoin et au plus vite
- éviter le coût important de réorientation/recentrage alors que le développement est très avancé – de diminuer les risques et le stress :
- la mise en production devient une activité quotidienne et maîtrisée - mise en production de petits morceaux de code bien identifiés
- ciblage rapide du code défectueux, avec retour en arrière facilité
- prise en charge des demandes (évolutions, corrections...) au fil de l'eau
- mises en production tous les 6 mois : les demandes affluent pour ne pas manquer ce train.
du build au déploiement continu
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
du build au déploiement continu
écosystème de développement
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
du build au déploiement continu
IDE
L'IDE (Integrated Development Environment) est l'outil le plus utilisé par le développeur. Il intègre beaucoup de plugins (Maven, Git...) permettant de faciliter son travail.
Les plus populaires dans le monde Java sont :
Rappel : le plus important dans un projet, c'est le code en lui-même, pas l'outil avec lequel on l'écrit.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – IntelliJ : l'équivalent d'Eclipse, avec un noyau et des plugins.
– Spring Tools : basé sur Eclipse, avec un ensemble de plugins orientés vers le développement basé sur la pile Spring – Eclipse : IDE comportant un noyau et de nombreux plugins, que l'on peut ajouter suivant les besoins
– VSCode : IDE léger pouvant servir à beaucoup de langages.
du build au déploiement continu
build automatique : Maven, Gradle
L'une des briques de base à mettre en place est la construction automatisée du logiciel.
Il faut que le processus de build :
Les 2 outils les plus populaires dans le monde Java sont :
Cet outil se situe au coeur du processus d'intégration continue car il est utilisé à la fois par :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – puisse être rejoué en un clic souris ou en une ligne de commande
– puisse s'exécuter sur différents environnements, y compris hors de l'IDE – puisse être exécuté manuellement ou automatiquement par un outil – exécute les tests (unitaires, d'intégration...).
– Maven : le plus répandu chez Orange – Gradle : de plus en plus populaire.
– le développeur sur son poste (dans son IDE par exemple)
– l'outil d'intégration continue pour produire l'artefact de livraison (jar, war...).
du build au déploiement continu
gestion des sources : Git
L'autre brique fondamentale à mettre en place est le gestionnaire de sources.
Il permet :
Git est le gestionnaire de sources préconisé.
Voici un article intéressant pour une gestion efficace des branches avec Git.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – la gestion des versions des fichiers
– la gestion de la configuration du projet – le travail collaboratif
– la traçabilité, l’historisation
– la gestion du cycle de vie (avec les branches)
– la qualité des livrables (conséquence des points ci-dessus) – la reproductibilité du build.
du build au déploiement continu
plateforme de développement : GitLab
Les principales fonctionnalités de GitLab sont de :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – gérer des dépôts Git
– gérer les membres d'un projet et leurs droits – déposer des Issues pour lister les bugs
– proposer des Merge Requests pour fusionner les branches
– lancer des pipelines d'intégration et de déploiement continus via le module GitLab CI/CD – fournir un Wiki pour la documentation.
du build au déploiement continu
intégration continue
Plus on découvre une erreur tard, plus son coût de correction est élevé.
Une fois le build automatisé et les sources gérées en configuration, il est possible de passer à l'étape suivante : l'intégration continue (continuous integration).
Elle doit :
Des environnements de tests sont créés à la volée puis supprimés lors de ces phases.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
– valider la capacité à construire le livrable à tout moment, à partir des sources placées en configuration – lancer les tests (unitaires, de performance, de sécurité, d'intégration...)
– s'exécuter après chaque modification des sources en configuration (dans l'idéal).
du build au déploiement continu
intégration continue : GitLab CI/CD
GitLab CI/CD (continuous integration/ continuous deployment) est un module de GitLab, qui permet de mettre en oeuvre facilement un pipeline d'intégration et de déploiement continu, en ajoutant à la racine du projet un fichier au format yaml : .gitlab-ci.yml.
Jenkins est un autre outil d'intégration continue.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
du build au déploiement continu
inspection continue
L'inspection continue (continuous inspection) fournit des tableaux de bord s'appuyant sur des métriques :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – les duplications de code
– le respect des règles de programmation, confrontées à des jeux de bonnes pratiques
– le calcul de la complexité du code (nombre de lignes par classes, couplage entre les classes…) – le taux de documentation
– la couverture de code par les tests unitaires
– le bilan d'exécution des tests unitaires et d'intégration – l'évolution dans le temps de la qualité de code du projet – détection de failles de sécurité
– ...
du build au déploiement continu
inspection continue
Un certain nombre d'outils permettent d'analyser le code et les dépendances du projet :
Attention : ces outils permettent de s'assurer que le code est bien écrit (lisible, maintenable, évolutif, sans vulnérabilités connues...), mais pas qu'il répond aux besoins. C'est le rôle des tests (unitaires, d'intégration, d'acceptance...).
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – Dependency-Check : détection de dépendances comportant des vulnérabilités connues – Fossology : vérification des licences utilisées dans le projet
– SonarQube : analyse de code pour évaluer sa qualité et détecter des problèmes de sécurité – Coverity : détection de vulnérabilités dans le code
– CheckMarx : détection de vulnérabilités dans le code – jaCoCo : couverture de tests.
du build au déploiement continu
inspection continue : SonarQube
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
du build au déploiement continu
livraison continue : GitLab CI/CD
Une fois le processus d'intégration/inspection continue maîtrisé, on peut envisager l'étape suivante : la livraison continue (continuous delivery).
Le livrable généré peut être déployé automatiquement sur un serveur d'intégration, techniquement le plus proche possible de la plateforme de production.
Il passera également des tests d'acceptation (acceptance tests) qui consistent à vérifier :
Ces tests peuvent être manuels, mais le mieux est de les automatiser. Il serait dommage d'avoir des plateformes disponibles en quelques minutes, mais que les tests manuels prennent 15 jours.
Une fois ces tests passés, le livrable peut être déployé sur la plateforme de production, soit :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – les non-régressions fonctionnelles
– la bonne couverture du besoin.
– manuellement : lancement d'un script à la main
– automatiquement : on peut alors pousser le processus jusqu'au bout.
du build au déploiement continu
déploiement continu : GitLab CI/CD
Le déploiement continu (continuous deployment) consiste à déployer automatiquement le livrable en production, sans intervention manuelle.
Cela veut dire que :
L'ensemble contribue à rassurer au moment souvent stressant et critique de la mise en production.
Note : veiller à ce que l'application reste très intuitive car il n'est plus possible de former les utilisateurs à chaque mise en production.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
– à chaque commit dans la gestion des sources (ou très régulièrement), la nouvelle fonctionnalité/la correction de bug se retrouve en production en quelques minutes
– une application peut être mise en production plusieurs fois par jour – en cas de problème, le retour en arrière est très simple.
les niveaux de Cloud
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
les niveaux de Cloud
contrôle ou abstraction ?
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
les niveaux de Cloud
contrôle ou abstraction ?
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
les niveaux de Cloud
du IaaS au SaaS
IaaS (Infrastructure as a Service) : le projet gère des machines virtuelles. Il doit installer toute la pile logicielle (OS, serveurs web, bases de données, application...) et gérer tout le cycle de vie de la VM.
CaaS (Container as a Service) : le projet gère des conteneurs (Docker notamment). Il peut potentiellement déployer n'importe quelle techno, et continue de gérer le cycle de vie (backup, versions, patchs).
PaaS (Platform as a Service) : le projet ne livre que l'application (qui doit être compatible avec les technologies supportées par le PaaS). Le PaaS instancie rapidement et à la demande des environnements d'exécution. Il prend en charge également des problématiques telles que la sécurité, la disponibilité, le dimmensionnement, la redondance... Les produits d'infrastructure utilisés (serveur d'applications, patchs de
sécurité, technologies supportées, services offerts...) sont gérés par le PaaS (une équipe dédiée).
FaaS (Function as a Service) : le projet livre de très petites unités exécutables. Le process démarre et s'arrête à la demande. Facturation a l'execution time du process.
SaaS (Software as a Service) : l'utilisateur final accède (via abonnement en général) aux logiciels via le web, sans devoir les installer en local.
Il utilise donc toujours la dernière version disponible. Quand un projet consomme une API, cette API peut être vue comme un SaaS.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
les niveaux de Cloud
PaaS : Cloud Foundry
Cloud Foundry (CF) est un PaaS open source développé par Pivotal. Il supporte plusieurs langages et frameworks, tels que Java, Node.js, PHP, Python, Ruby... On y manipule des packages applicatifs.
La configuration de l'application (environnement, services...) se fait dans un fichier manifest.yml situé à la racine du projet : Une instance nommée AeroFoundry est déployée côté DTSI.
Une fois l'application construite (par l'intégration continue...), pour la déployer, le PaaS va :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – instancier l'environnement d'exécution
– instancier des services utilisables par l'application (persistance, MOM, messagerie, logs, monitoring...)
– gérer dans le temps les évolutions/contraintes : la scalabilité, la volumétrie, la QoS (certains services offrent plusieurs niveaux).
les niveaux de Cloud
CaaS - PaaS : Kermit
Kermit est une autre offre PaaS-CaaS interne Orange. Il s'appuie sur l'outil Red Hat OpenShift (jouant le rôle de PaaS) qui est une usine à images Docker (conteneurs), le tout orchestré par Kubernetes.
Le projet a plusieurs possibilités pour déployer son application. Il peut fournir à Kermit :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – le livrable (exemple .jar) en sortie de l'intégration continue => PaaS
– l'image Docker qu'il a construite => CaaS
– les sources du projet, Kermit se chargeant de construire lui-même l'application et l'image Docker qui convient et de l'instancier.
les niveaux de Cloud
ça PaaS ou ça CaaS ? Cloud Foundry ou Kermit ?
Privilégier Cloud Foundry quand :
Privilégier Kermit quand :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – l'application respecte les 12 factors
– l'application est basée sur les standards du marché en terme de : - pile logicielle
- modèle de programmation : stateless, architecture évolutive
– l'application peut s'appuyer sur des services disponibles sur un marketplace de CF (SSO, base de données, cache, messaging...) – l'équipe ne veut pas se préoccuper de l'infrastructure sous-jacente (et de ses évolutions).
– l'application a des besoins spécifiques (sur les protocoles réseaux utilisés, les middlewares, le langage...) – l'équipe doit garder un contrôle accru sur la plateforme
– l'équipe possède une large expertise sur toute la chaîne du build au run.
monolithe ou microservices ?
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
monolithe ou microservices ?
cas des applications monolithiques
Les applications monolithiques ont certaines propriétés qui peuvent être des avantages comme des inconvénients.
Un langage unique sur toute l'application :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – avantages :
- montée en compétences plus facile sur toute l'application - entraide facilitée entre membres du projet
- homogénéité du code – inconvénients :
- ce langage n'est peut-être pas le plus adéquat selon les modules - fort couplage entre les modules
- même si les technologies évoluent sur le marché, on doit continuer à coder avec l'existant (langages ou frameworks obsolètes) même pour les nouvelles fonctionnalités.
monolithe ou microservices ?
cas des applications monolithiques
Toute l'application est déployée au même endroit :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – avantages :
- plus simple à déployer
- pas de problème réseau entre composants
- gestion des problèmes transversaux simplifiés (configuration, logs...) – inconvénients :
- il faut souvent mettre en place une scalabilité verticale (augmenter la puissance des machines)
- on provisionne des machines surdimensionnées dont les capacités seront réellement utiles qu'à de rares moments - il faut toujours + de CPU, de RAM... car les applications sont de plus en plus gourmandes
- la loi de Moore tendant à arriver à ses limites, on ne peut plus trop compter sur les progrès des machines pour scaler verticalement dans le futur
- chaque modification mineure dans l'application entraîne son redéploiement complet - en cas de problème, toute l'application tombe.
monolithe ou microservices ?
cas des applications monolithiques
Or, dans une application, tout n'est pas uniforme et homogène. Certaines parties sont plus ou moins :
Dans une application monolithique, toutes ces contraintes sont appliquées de fait partout. On doit faire des compromis (répondre globalement à la plupart des exigences).
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – critiques en terme de fonctionnalités et/ou de sécurité
– stables dans le temps – difficiles à coder
– sollicitées (pics de charge...).
monolithe ou microservices ?
cas des microservices
Pour les microservices, là encore, certaines propriétés peuvent être vues comme des avantages ou des inconvénients, qui sont à peu près inverses à ceux des applications monolithiques.
Chaque module est spécialisé dans une fonctionnalité, en tenant compte de ses contraintes :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – avantages :
- organisation de l'équipe projet et efforts mis en place (tests, sécurisation) en fonction des modules :
- critiques, mises à jour fréquentes, données sensibles : les meilleurs développeurs, beaucoup de tests, sécurisation renforcée, automatisation...
- très sollicités : tests de charge, monitoring + poussé...
- non critiques, peu de charge : montée en compétence des débutants, gestion en best effort...
- ouverture sur internet, 24/7 : métriques d'usage de l'application, tests avec les outils du public...
- utilisation de la technologie la mieux adaptée au contexte (à un instant T)
- réécriture/migration simplifiée des modules écrits avec des technologies obsolètes dans des nouvelles technologies – inconvénients :
- plusieurs langages à apprendre - code très hétérogène
- difficultés d'entraide entre collègues.
monolithe ou microservices ?
cas des microservices
Architecture distribuée :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – avantages :
- favorise la scalabilité horizontale
- instanciation à la demande de petites machines (conteneurs...) - chaque noeud d'un module est identique à son voisin
- seuls les microservices très sollicités sont répliqués – inconvénients :
- il faut s'appuyer sur une infrastructure solide (plateformes, réseau...) - ajout de nouveaux outils pour orchestrer toute l'application
- vue d'ensemble de l'application plus complexe
- moins de lisibilité sur qui appelle quoi, difficulté de tracer le parcours client - plus de composants donc plus de risques que l'un d'eux plante
- un problème insignifiant sur un module peut faire tomber un autre module, et difficulté d'en trouver la cause - problèmes réseau : latence réseau possible (temps de réponses dégradés), coupures...
monolithe ou microservices ?
cas des microservices
Pour les applications monolithiques, on fait tout pour qu'aucune panne n'intervienne.
Pour les microservices, il faut intégrer le fait que les pannes adviendront inévitablement du fait de la multiplication des composants. Il faut faire en sorte que l'application réagisse bien dans ces cas là (Design for Failure) :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
– redondance et décentralisation des composants : physiques, virtuelles (VM), de datacenters – chaque composant doit être prêt à une panne d'infrastructure sous-jacente
– passer en mode dégradé ponctuellement
– traiter automatiquement la défaillance (arrêt/redémarrage du composant...) – savoir détecter rapidement les problèmes et remonter à leur source
– analyser à froid les causes pour améliorer le système (pas besoin d'être dans l'urgence) – ...
monolithe ou microservices ?
quand passer aux microservices ?
Toute application n'est pas éligible pour passer aux microservices.
Voici quelques points à prendre compte :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
– investissement non négligeable au début du projet (outillage, organisation, pratiques de développement...) – la maturité de l'équipe sur les microservices : ne pas être trop ambitieux dès le départ
– les avantages des microservices s'accompagnent aussi de gros inconvénients – l'apport des micro-services est surtout valable à moyen et long terme :
- si la durée de vie de l'application est courte (sortie d'un film...), il n'y aura pas d'évolutions dans le temps et sa taille sera assez petite à priori
– si l'application est assez simple :
- commencer par isoler le frontend (s'il y en a un) du backend, qui expose une API REST
- côté backend, démarrer par un monolithe puis isoler et sortir des fonctionnalités précises au fur et à mesure que le besoin s'en fait sentir (gestion de la sécurité, des logs, un domaine fonctionnel...)
– si des domaines marqués sont identifiables dès le début, les séparer en mini-applications, pas forcément tout de suite en microservices – ...
twelve-factor apps
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
twelve-factor apps
objectifs des twelve-factor apps
Les 12-factor apps sont des applications respectant 12 règles ou critères dans le but d'être délivrées en tant que (micro)services.
Ces applications sont conçues pour :
Note : ces 12 facteurs sont indépendants de tout langage de programmation, utilisant tout type de services externes (base de données...).
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – offrir une grande portabilité entre les environnements d'exécution
– être déployées sur des plateformes Cloud
– minimiser les divergences entre les plateformes de développement, tests, production – permettre le déploiement continu
– pouvoir augmenter la scalabilité de façon rapide
microservices et twelve-factor apps
les 12 facteurs
1. base de code
Une base de code unique par application/microservice, gérée dans un gestionnaire de sources (avec des branches...). A partir de cette base de code, on peut avoir plusieurs instances de l'application déployées (en développement, en test, en production...).
2. dépendances
Les dépendances doivent toujours être déclarées explicitement, sans dépendre de l'existence implicite de packages ou librairies fournis par le système.
3. configuration
Avoir une stricte séparation entre le code et la configuration (portée par l'environnement). Ainsi, on peut déployer le même code sur plusieurs environnements différents, en modifiant seulement la configuration (fichiers externalisés, variables d'environnement, serveur de configuration...).
C'est un prérequis au facteur 5 (build, release, run).
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
microservices et twelve-factor apps
les 12 facteurs
4. services externes
Il faut gérer les services externes locaux ou distants de la même manière. Chaque service externe est une ressource ayant un faible couplage avec l'application. Ces ressources peuvent être attachées/détachées/remplacées à la demande suivant les situations.
5. build, release, run
Avoir une séparation stricte entre les étapes de build, release et run :
6. processus
Le(s) processus d'une application est (sont) sans états (stateless) et ne partage(nt) rien. Toute donnée à persister (même les sessions HTTP utilisateurs) doit l'être dans un service externe statefull comme une base de données (mais pas en mémoire ni sur le disque dur local, qui peuvent être effacées par redémarrage du serveur...). Si un noeud tombe, un autre peut prendre le relais.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – build : transformation du code en un paquet autonome et exécutable
– release : ce paquet exécutable + la configuration du déploiement courant – run : exécution de l'application dans un environnement.
microservices et twelve-factor apps
les 12 facteurs
7. associations de ports
L'application est auto-contenue (standalone) et expose ses services (ex : par HTTP) en les associant à un port qu'elle écoute pour traiter les requêtes. Une application peut ainsi devenir le service externe d'une autre en lui fournissant son URL d'accès.
8. concurrence
Structurer l'application afin d'assigner à chaque service son processus. Cela permet de gérer au mieux le dimensionnement d'une
application, service par service, suivant leurs propres contraintes. Ainsi, il est simple d'ajouter/supprimer des processus (serveurs) en fonction de la charge (scalabilité horizontale).
9. jetable
Les processus doivent être jetables : démarrés rapidement et arrêtés gracieusement. Les arrêts doivent terminer le travail en cours et stopper la prise en charge de nouveaux travaux, mais aussi être robustes aux arrêts brutaux (via une file de messages...).
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
microservices et twelve-factor apps
les 12 facteurs
10. parité développement/production
Garder le développement, la validation et la production aussi proches que possible pour favoriser le déploiement continu. Les
mêmes personnes développent et déploient, ceci de façon régulière et automatisée (toutes les qques heures, voire jours). Les développeurs doivent utiliser au maximum les mêmes ressources externes que la production (base de données...).
11. logs
Une application ne doit pas gérer le stockage de ses logs (dans des fichiers) mais les considérer comme des flux de sortie. Ces flux seront capturés par l'environnement qui pourra les aggréger avec les logs d'autres processus, les archiver...
12. processus d'administration
Les processus ponctuels d'administration devraient être lancés dans un environnement identique aux processus standards de l'application. Le code d'administration doit être livré avec le code de l'application pour éviter les problèmes de synchronisation.
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
microservices et twelve-factor apps
Spring Boot et les 12 facteurs
Spring Boot permet de répondre (ou au moins d'aider) à certains des 12 facteurs :
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)
– 2. dépendances : les starters définissent la grande majorité des dépendances utiles au projet
– 3. configuration : facilité de lire des valeurs définies dans des fichiers properties (avec profils) ou des variables d'environnement grâce aux classes et annotations adéquates
– 4. services externes : l'approche microservice de Spring Boot pousse à considérer toute ressource (locale ou distante) de la même manière (notamment via des APIs)
– 7. associations de ports : une application Spring Boot est standalone grâce au serveur embarqué, et expose ses services sur un port HTTP configurable (application.properties externalisé)
– 8. concurrence : Spring Boot est orienté microservices, chacun ayant son processus avec ses contraintes et ses spécificités, et la possibilité de faire de la scalabilité horizontale fine (par microservice)
– 9. jetable : une application Spring Boot démarre en quelques secondes et peut s'arrêter gracieusement (endpoint /shutdown fourni par Actuator)
– 10. parité développement/production : grâce au serveur embarqué, le même fat jar/war peut-être déployé en développement, test, qualification et production.
– 12. processus d'administration : Spring Actuator offre des endpoints (URLs) de monitoring.
liens utiles
de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal) – Maven, Gradle
– Eclipse, Spring Tools, IntelliJ, VSCode – GitLab, Git
– Jenkins
– Dependency-Check, Fossology, SonarQube, Coverity, CheckMarx, jaCoCo – Spring Cloud
– Cloud Foundry
– Red Hat OpenShift, Kubernetes – Docker
