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.
Continuer la lecture de Installation/configuration de slaves JenkinsIl y a plusieurs manières d’installer Jenkins sous Linux, que j’ai essayé de comparer.
Continuer la lecture de Comment installer Jenkins : sous Docker, via un package/repo ou à la main?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)
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 
).
Continuer la lecture de Sécuriser les mots de passe jdbc du server.xml d’un Tomcat
