Vous êtes sur la page 1sur 41

Orange septembre

2020

de Spring à Spring Boot


Spring Boot et la démarche DevOps
industrialiser ses développements Java
sommaire
– enjeux du DevOps
– du build au déploiement continu
– les niveaux de Cloud
– monolithe ou microservices ?
– twelve-factor apps

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


enjeux du DevOps

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


enjeux du DevOps
Le DevOps a pour avantages :

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

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)


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 :

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

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)


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 :

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

Les 2 outils les plus populaires dans le monde Java sont :

– Maven : le plus répandu chez Orange


– Gradle : de plus en plus populaire.

Cet outil se situe au coeur du processus d'intégration continue car il est utilisé à la fois par :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


du build au déploiement continu
gestion des sources : Git
L'autre brique fondamentale à mettre en place est le gestionnaire de sources.

Il permet :

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

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)


du build au déploiement continu
plateforme de développement : GitLab
Les principales fonctionnalités de GitLab sont de :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

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

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)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


du build au déploiement continu
inspection continue
Un certain nombre d'outils permettent d'analyser le code et les dépendances du projet :

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

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)


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 :

– les non-régressions fonctionnelles


– la bonne couverture du besoin.

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 :

– manuellement : lancement d'un script à la main


– automatiquement : on peut alors pousser le processus jusqu'au bout.

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

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

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)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


les niveaux de Cloud
ça PaaS ou ça CaaS ? Cloud Foundry ou Kermit ?
Privilégier Cloud Foundry quand :

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

Privilégier Kermit quand :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


monolithe ou microservices ?
cas des applications monolithiques
Toute l'application est déployée au même endroit :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

– critiques en terme de fonctionnalités et/ou de sécurité


– stables dans le temps
– difficiles à coder
– sollicitées (pics de charge...).

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)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


monolithe ou microservices ?
cas des microservices
Architecture distribuée :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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) :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


monolithe ou microservices ?
quand passer aux microservices ?
Toute application n'est pas éligible pour passer aux microservices.

Voici quelques points à prendre compte :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


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 :

– 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

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)


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 :

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

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)


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 :

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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


liens utiles
– 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

de Spring à Spring Boot - Spring Boot et la démarche DevOps (Orange internal)


merci

Vous aimerez peut-être aussi