Intégration/Déploiement Continue sur OpenShift

Aujourd’hui, je m’attaque à la problématique d’Intégration et de Déploiement Continue avec OpenShift. Mes interrogations sont les suivantes: Qu’apporte une plateforme Docker ? Quels sont les gains en productivité ? Quels intérêts pour les développeurs ? pour les Ops ? Quelles contraintes sur un projet classique JEE ? Bref, pour m’aider à y répondre, j’utiliserai le superbe projet CI/CD Demo on OpenShift de Siamak Sadeghianfar comme base. Il est très complet, merci Siamak 😉 . Cependant je n’ai pas résisté à y apporté une touche personnelle suite à quelques envies et incompatibilités… Mon environnement Windows 10 et la finalisation de MiniShift en 1.0-rc2 en sont probablement la cause.

Objectifs

Mon objectif principal est d’ accélérer les déploiements des applications Java sur des environnements prêt à consommer. La finalité est de déployer une version stable d’une application JEE dans un environnement “STAGE” après l’avoir testée et évaluée.

Pour cela, les outils doivent me permettre un certain nombre d’actions sur le logiciel en cours de développement:

  1. construire,
  2. vérifier la qualité,
  3. archiver,
  4. déployer
  5. exécuter
  6. tester
  7. mesurer.

Je vais utiliser 2 environnements différents, un pour les tests unitaires, l’autre pour les tests d’intégration. Openshift m’apportera son aide sur la gestion de ces environnements avec

  1. leur définition,
  2. le déploiement des machines,
  3. le portage des instances.

Quand à l’intégration continue (construction, mesure et archivage), les outils opensource Jenkins, Sonar et Nexus sont mes amis 😉 .

Ma vision globale de la problématique de CI/CD est celle-ci:

Toutefois, une précision de vocabulaire s’impose.

La notion d’environnement dans OpenShift est appelé PROJET (un namespace kubernetes). Cela est similaire à un sous-réseau où les instances dockers (pods) peuvent communiquer entre elles.

Dans la suite de l’article, je parlerai d’environnement pour PROJET “OpenShift” et projet pour PROJET “Maven”.

Lire la suite “Intégration/Déploiement Continue sur OpenShift”

Gravitee sur OpenShift

Voici ma très courte procédure d’installation de la solution d’API Management Gravitee.io sur Openshift. Du simple et rapide comme j’aime 🙂 .

Objectif

Gravitee se compose de 2 DB: ElasticSearch et MongoDB ainsi que 3 modules: UI, API et Gateway.

Je souhaite avoir un environnement simple et bien compartimenté pour mes futurs projets d’API Gravitee, quelque chose comme ceci:

Lire la suite “Gravitee sur OpenShift”

Doctrine de l’Architecture d’Entreprise

Au cours de mes missions en Architecture d’Entreprise, je rencontre souvent la difficulté à expliquer cette activité. Entre méthode, objectifs, enjeux, implémentations, patterns, je perds vite mes interlocuteurs. J’ai cherché comment simplifier mon discours. J’ai bien trouvé de nombreux ouvrages sur TOGAF, Zachman ou Federal EA. Ils décrivent comment dérouler ces méthodes… mais leur compréhension est délicate, les concepts présentés sont théoriques et il faut une solide expérience pour bien les appréhender. Je n’ai finalement rien trouvé de mieux que la description du CIGREF sur le sujet.

J’en reprends d’ailleurs la définition suivante. A mes yeux, elle résume bien le scope de l’EA.

« L’Architecture d’Entreprise est la logique structurante pour les processus métiers et l’infrastructure informatique, reflétant les exigences d’intégration et de standardisation du modèle opératoire de l’entreprise. L’architecture d’entreprise fournit une vision à long terme des processus, des systèmes et des technologies de l’entreprise afin que les projets individuels puissent construire des capacités et non pas simplement répondre à des besoins immédiats. »
J. W. Ross, P. Weill (MIT) et D. C. Robertson (IMD) “Enterprise Architecture as Strategy”, HBS Press, 2006

Mon expérience et mes clients m’ont amené à être très pragmatique dans mon quotidien et dans mon approche. De part mes appétences techniques, j’aime comprendre les aboutissements et l’atterrissage des concepts. D’autre part, il est coûteux et long de propager une démarche méthodologique. C’est en plus assez antinomique avec l’agilité actuelle des projets. Pour quelques clients, j’ai synthétisé une vision personnelle dans un ensemble réduit de règles. Elles forment ma Doctrine de l’Architecture d’Entreprise. Sa diffusion vers les MOA, les Chefs de projets et la Direction est de ce fait plus aisée. Concrètement, les détails sont explicités lors des workshop projets et disponibles dans un Wiki annexe. Je cherche ici à réduire la complexité de la démarche. A rendre le discours de l’EA très concret. Le blabla et les détails techniques sont volontairement cachés. Bref, ces règles sont pour moi la face visible de l’iceberg de l’Architecture d’Entreprise.

Je suis conscient qu’elles demanderaient des explications et des éclaircissements. De ces règles, qui sont presque des objectifs pour certaines, il en découle des concepts, des certitudes et des implémentations pragmatiques. J’espère en tout cas vous démontrer que l’Architecture d’Entreprise n’est pas une idée de l’esprit ou une démarche de de théoriciens lunatiques mais que TOUS les acteurs de l’Entreprise y sont gagnants :-O .

Lire la suite “Doctrine de l’Architecture d’Entreprise”

Premiers pas avec MiniShift

Voici mes 1ers pas avec MiniShift, la version simple et légère de OpenShift RedHat à installer sur son Windows 10. J’ai déjà quelques VM sous VirtualBox. Je vais donc continuer avec cette contrainte.

Je vais juste vérifier que la plateforme s’exécute correctement avec une application JEE (on ne se refait pas) de démonstration.

Lire la suite “Premiers pas avec MiniShift”

TIMWICamp – Share your brain – 2017/02

En tant que membre de l’alliance TIMWI, j’ai le plaisir de participer aux partages de connaissance, les TIMWICamp. Sur un après-midi festif et convivial, 2 ou 3 sujets sont présentés et échangés aux salariés et freelance membres de l’alliance.

Voici ma prise de note de la dernière édition, la session du 30 janvier. J’espère que cela reste suffisamment lisible pour vous 😉 . Voici les sujets abordés lors de cette demi-journée:

  • REX Agile multi-équipes
  • News éditeurs
  • Outil Microsoft Message Analyzer

Lire la suite “TIMWICamp – Share your brain – 2017/02”

Choregraphie de services

Pour changer, je vous propose une vidéo d’un petit projet pour illustrer la chorégraphie de services. Pour cela, j’utilise la suite Oracle SOA en version 12.1.

L’objectif est d’expliciter comment réaliser une intégration ou une coordination de services en découpant la complexité. Il est difficile à produire puis à maintenir un système complexe et riches en règles métiers. J’applique donc le principe « diviser pour régner ».

Dans mon exemple, je réalise une intégration dans une base de données afin de vérifier et démontrer plus facilement l’aspect transactionnel.

Le schéma global des services est assez simple :

diapositive5

  • Un service de coordination reçoit la demande d’intégration
  • 3 services sont appelés :
    • L’intégration des champs field1 pour 2 notions (tableA et aTableB)
    • L’intégration des champs field2 pour les mêmes notions
    • L’ajout d’une dépendance particulière.

Voici cette démonstration :

[embedyt] http://www.youtube.com/watch?v=xh2POb-Kj6c[/embedyt]

 

Le code est disponible sur Bitbucket: https://bitbucket.org/middlewaresolutions/soa12-dbadapterdemo

J’y ai finalement ajouté une chorégraphie avec WebService. Il s’agit du projet composite PersistAandBWS. Il est similaire à PersistAandB de la vidéo. Vous le trouverez dans le code git.

Au final, ce cas répond à quelques questions couramment posées :

Comment propager une transaction ?

Réponse : Pour le DirectBinding: c’est automatique. Pour les WebServices référents: préciser WSAT12 + MANDATORY.

Est-il possible de travailler sur une même notion dans plusieurs services ?

Oui. Les opérations sont réalisées dans l’ordre dicté par le service de chorégraphie. L’enregistrement est enrichi progressivement.

Le merge du DBAdapter est-il suffisant et efficace ?

Oui. Il faut toutefois faire attention au mapping avec l’attribut « private-owned » des relations. Par défaut, il est à true, ie. les dépendances ne sont par mergées, il est donc préférable mais plus coûteux de le positionner à false pour recharger les instances liées.