Objectif : faire une analyse SonarQube à chaque Pull Request, et afficher le résultat dans la PR de Bitbucket cloud
Catégorie : Java
Gitlab permet de se brancher avec Jenkins pour y faire l’intégration continue.
Spring Boot est un excellent accélérateur et cadre pour les applications spécifiques Java. J’ai eu l’occasion d’y faire passer une application dite « legacy » : c’est plus compliqué que de partir de zéro, mais ça vaut le coup.
Jenkins propose un architecture distribuée basée sur des noeuds (aussi appelée master/slave) qui est très efficace et flexible.
Elle permet facilement de répartir des builds sur des machines, qui peuvent être sur des OS différents, avec installation à la volée des outils de build.
Je ne vais pas ré-écrire la documentation de Jenkins, mais donner un retour d’expérience sur des cas que j’ai eu à traiter.
Il y a plusieurs manières d’installer Jenkins sous Linux, que j’ai essayé de comparer.
Besoin : sur une appli Java, compenser la suppression du XA sur un couple JDBC–JMS.
Les classes TransactionSynchronization et SimpleThreadScope du framework Spring nous ont grandement rendu service pour ça.
Contexte : développement d’applications Java/Spring/Hibernate, avec données en bases Oracle. Build géré par Maven, exécutant des tests unitaires (voire tests d’intégration) sur un schema Oracle dédié à chaque développeur. Plateforme d’intégration continue (PIC, gérée par Jenkins) exécutant les TUs sur un schema Oracle par application.
Objectifs :
- réduire le temps de build sur les postes de dev
- permettre de basculer d’un projet à un autre plus facilement (sans avoir à recréer la structure de son schema Oracle)
- alléger l’installation/configuration des postes de dev
Idée : faire passer les tests unitaires sur une base en mémoire (H2) plutôt que sur Oracle
Spoiler : on a réussi à le mettre en place… mais on ne s’en est finalement quasiment pas servi.
Besoin : pouvoir comparer un « checksum » des données de certaines tables (en base de données, ou dans un MDM), pour s’assurer que les données y sont fonctionnellement identiques.
Contexte : certaines données (dites de référentiel) sont dupliquées et synchronisées entre plusieurs systèmes/applications. Ce contrôle permet de s’assurer que la synchronisation fonctionne bien.
Contraintes : la structure des tables peut être légèrement différente d’un système à l’autre, et elles ne sont pas toujours accessibles directement en SQL (cas du MDM : progiciel EBX dans notre cas)
Besoin : être capable de chiffrer des données sensibles d’une entreprise, pour pouvoir les faire transiter entre plusieurs applications.
Périmètre : chiffrement d’une chaine de caractères, pas d’un fichier ou d’un filesystem.
Enjeu : être capable de raisonnablement sécuriser le contenu, tout en étant interopérable entre différentes technologies.
Par défaut, les dataSources déclarées dans Tomcat affichent le mot de passe jdbc en clair dans conf/server.xml.
Dans pas mal d’entreprises, le répertoire de tomcat est accessible en lecture à de nombreuses personnes. C’est très pratique pour diagnostiquer, mais pose un problème de sécurité en exposant ce mot de passe.
Voici quelques pistes d’amélioration que j’ai investiguées, en essayant de trouver un équilibre entre les besoins des développeurs et ceux de l’exploitation (oui, ça ressemble à de la démarche devops 
).