Plus récemment, j’ai souhaité mettre à disposition une image Docker de l’ application Spring Petclinic basée sur Angular 1 et Spring Boot. Ce billet explique :

1. Comment l’image Docker a été construire
2. Et comment l’utiliser pour tester Petclinic

L’utilisation conjointe de Maven pour réaliser des release et de git-flow peut s’avérer laborieuse. En effet, lorsque vous travaillez avec des branches (quel que soit le SCM), une bonne pratique veut que chaque branche possède son propre numéro de version. Afin d’éviter des collisions de nommage, cette pratique devient indispensable lorsque vous utilisez un serveur d’intégration continue pour publier les artefacts construits dans un repo Maven. Une fois une branche crée à partir d’une autre, chaque branche vit sa vie. Des releases Maven peuvent être réalisées de part et d’autre. Là où cela devient tendu, c’est lorsque vous devez reporter les commits d’une branche vers une autre. Des conflits de merge sur le numéro de version Maven apparaissent alors inévitablement. Lorsque votre application multi-modules comporte 15 pom.xml, c’est 15 conflits qu’il va falloir gérer manuellement. Il est effectivement risqué de conserver aveuglément la version du pom.xml local ou distant, car d’autres changements (et vrais conflits) peuvent se produire dans d’autres sections du pom.xml.

Comme cas d’études, prenons l’exemple du repo Git helloworld :

Cela fait un an que je contribue activement à la maintenance de l’application Spring Petclinic. Développée initialement par les créateurs du framework Spring, Juergen Hoeller et Rob Harrop, cette application démo a évolué au fur et à mesure des montées de version du framework. Elle est passée d’une approche full XML, à une approche mixte annotations + XML. Une branche est également disponible pour la configuration Java. Récemment, nous avons mis à disposition une branche basée sur Spring Boot 1.4.0. L’objectif de ce billet est de vous expliquer quels ont été les impacts d’une telle migration.

J’ai eu l’opportunité d’assister à une journée de découverte de la plateforme Cloud de Google. Dispensée dans les locaux parisiens de Google, cette formation d’une journée était animée par Didier Girard, Google Developer Expert et Directeur Général Délégué de Sfeir. Ce fut l’occasion de découvrir la diversité des offres proposées par la Google Cloud Platform et de pouvoir les comparer à celles, plus médiatisées, d’autres géants du web tels Amazon (AWS) et Microsoft (Azure).

Large, la gamme de services Google Cloud Platform est répartie en 4 offres :

• Compute : App Engine, Container Engine, Compute Engine
• Storage : Bigtable, Cloud Storage, Cloud SQL, Cloud Datastore
• Big Data: BigQuery, Pub/Sub, Dataflow, Dataproc, Datalab
• Machine Learning: Vision API, Machine Leargning, Speech API, Translate API

Cet article se focalisera sur l’offre Compute. Mais avant d’aller plus loin, arrêtons-nous un moment sur ce qui est l’une des forces de la plateforme Cloud de Google : son infrastructure.

Pour vous aider à choisir quelle conférence visionner sur la chaîne Devoxx FR 2016 de Youtube ou pour vous remémorer certaines chose, je mets librement à votre disposition les différentes notes que j’ai pu prendre sur mon laptop.

Les sujets sont variés : des Microservices avec Spring Boot et Spring Cloud, du Big Data avec Kafka et Elasticsearch, du Front End avec ECMAScript 2015 et React, du Java 8 et 9 ou bien encore de la méthodologie avec les revues de code et de la living documentation.

Certaines notes pourront être lues de manière autonome ; je pense par exemple au quickie Comment rater ses revues de code ? et à la conférence Stack Overflow behind the scenes. Pour être exploitables en l’état, d’autres notes demanderont à ce que vous ayez assisté à la conférence ou que vous ayez pu récupérer les supports de présentation.