Intégration continue : de Jenkins à Gitlab CI

L’intégration continue a toujours été un élément très important pour l’équipe technique du Groupe PSIH.
Lorsque nous nous appelions encore PMSIpilot et que nous ne maintenions qu’une seule suite logicielle, les tests, et la qualité en général, étaient déjà très importants. À l’époque, nous utilisions exclusivement Jenkins pour lancer nos jobs automatiquement.

Nous avons donc historiquement un cluster qui a évolué au fil des années. Nous avons commencé avec quelques slots puis nous sommes passés à quelque chose de plus important, avec une dizaine de serveurs (un maître et neuf esclaves) et donc beaucoup plus de slots. Cela nous allait parfaitement, d’autant qu’à cette époque nous n’utilisions pas de solution de gestion de code source telle que Github ou Gitlab.

Il y a environ 4 ans, nous avons décidé de migrer toute notre gestion de code source sur Gitlab et depuis, nous avons scrupuleusement suivi toutes ses mises à jour. Nous appliquons chaque mise à jour 1 mois après sa sortie officielle afin de bénéficier directement de tous les correctifs mineurs. Du coup, à un moment, nous avons hérité de Gitlab CI.

Nous n’avons pas commencé à l’utiliser tout de suite. Jenkins nous allait très bien malgré quelques problèmes liés à sa lourdeur et à sa complexité. Au fil du temps, ces problèmes sont devenus de plus en plus présents et nous avions une boucle de feedback de plus en plus longue sur les développements : il n’était plus possible d’attendre une demi-heure, voir plus, pour avoir le résultat de nos tests unitaires.
Gitlab CI était donc notre sauveur !

Nous avons donc commencé, petit à petit, à migrer les jobs les moins complexes vers Gitlab CI. Ce changement a été très bénéfique car, non seulement notre boucle de feedback a été drastiquement réduite, mais nous avons en plus un retour immédiat directement dans Gitlab, dans les Merge Requests. On peut donc facilement consulter les commentaires de revue de code et le statut de l’intégration continue.

Il nous restait un problème à régler : nous n’avons pas pu nous passer totalement de Jenkins. En effet, Gitlab CI tourne, chez nous, sur une infrastructure basée sur Docker et nous devons être capable de construire et lancer des machines virtuelles en intégration continue. Jenkins était déjà équipé pour cela et porter tous ces mécanismes dans Gitlab CI était trop coûteux. Du coup, les développeurs se retrouvaient souvent à passer de Gitlab à Jenkins afin de planifier correctement leurs jobs et consulter leurs statuts.

C’est comme ça que Jenklab CI est né !

Jenklab CI

Ce petit outil, écrit en Javascript et utilisable en ligne de commande ou via un conteneur Docker, utilise l’API de Jenkins et nous permet de faire un pont avec Gitlab CI : il est capable d’exécuter un job Jenkins depuis un pipeline Gitlab CI en injectant toutes les variables prédéfinies par l’environnement d’intégration continue de Gitlab.

Grâce à cela, nous avons pu régler les problèmes que nous avions : nous pouvons garder en l’état tous nos jobs qui construisent et déploient nos machines virtuelles et nous avons un retour direct dans Gitlab, dans l’interface des Merge Requests.

Jenklab CI se veut simple et efficace : il ne propose pas de fonctionnalité très avancée, juste le strict minimum pour garantir un confort d’utilisation de nos deux solutions d’intégration continue. En bonus, nous pouvons utiliser toutes les options proposées par Gitlab CI pour choisir quand lancer un job Jenkins (déclenchement manuel, automatique …)

J’ai déjà donc cité le fait que les variables de l’environnement Gitlab CI sont transmises à Jenkins, ce qui est idéal pour configurer automatiquement vos jobs en fonction de certains paramètres (branche Git à utiliser, dépôt à cloner …).

Le log du job Jenkins est affiché directement dans la console Gitlab CI, nous pouvons donc garder l’historique complet des exécutions même si, du côté de Jenkins, les logs sont purgés régulièrement.

Pour finir, Jenklab CI est capable d’annuler un job Jenkins lorsque le job correspondant est annulé dans Gitlab CI.

Nous utilisons cette solution depuis quelques mois maintenant pour tous nos jobs qui sont coûteux en temps, qui demandent une infrastructure plus complexe ou qui déploient des livrables (la construction et publication de nos RPMs par exemple). Nous sommes très satisfaits de cet outil.

Si vous souhaitez l’utiliser, n’hésitez pas à jeter un oeil au dépôt sur Github et éventuellement à nous soumettre vos remarques ou demandes d’évolution.


Le Groupe PSIH recrute des développeurs(euses) pour son équipe R&D. Si vous êtes intéressé(e)s, n’hésitez pas à consulter l’offre et à nous contacter.

 

Langages de programmation… Il y en a pour tout le monde

Notre principal produit chez PSIH est une plateforme décisionnelle extrêmement riche en fonctionnalités utilisée par plus de 700 établissements hospitaliers en France. Ceci nous amène à utiliser différents languages de programmation pour résoudre différentes problématiques techniques. Voici un aperçu de ces langages qui composent notre stack technique.

chart (2)

PHP

Tout a commencé avec du PHP, avant de passer à une architecture orientée micro-services, notre plateforme était composée d’une seule application monolithique en PHP. Avec l’architecture actuelle, PHP reste présent dans nombre d’applications fullstack Symfony2 mais aussi de services backend (PHP 5.6 pour le moment mais la migration vers PHP 7 est prévue). D’autres amis se sont joints à la fête.

Javascript

Javascript représente le language principal des différents frontends de la plateforme (ES 2015). Il est notamment utilisé dans un certain nombre d’applications AngularJS. Mais nous utilisons également javascript dans des outils et services NodeJS. Nous sommes également amenés à utiliser du Rhino pour la partie intégration de données.

Typescript

Nous avons entamé la migration Javascript ES6 vers Typescript sur certains projets et ce pour différentes raisons que je vous laisserai découvrir dans notre précédent article Why Typescript ? (Angular2, we are coming!)

Java

Java est utilisé dans différents services backend. Nous prévoyons une migration de Java au JDK8. Nous avions pour ainsi dire déjà amorcé la transition en utilisant Guava pour imiter les Optional et Lambda.

Less

Nos feuilles de styles sont écrites essentiellement en Less (pmsipilot-ui); un passage à Sass est envisagé avec la sortie de Twitter Bootstrap 4

Shell / Python / Ruby

Dans le cadre de l’industrialisation de la plateforme et du continuous delivery, nous sommes également amenés à utiliser différents du shellet du python pour du scripting et du ruby pour écrire des cookbooks Chef et configuration Vagrant.

SQL

le SQL (et PL/SQL) occupe forcément une partie importante de toute plateforme décisionnelle, notamment dans le développements de flux d’intégration et la génération de requêtes de reporting.

Le C

Pas énormément ok, mais on en fait quand même :).

Alors vous voulez vous joindre à la fête ?

 

Refactoring : Improving the design of existing code

Retranscription brute de pomme de la petite rétro diffusée en interne

Hier soir se tenait le book club de Lyon, organisé par le software craftmanship de Lyon. On était une petite dizaine, je vous fais un résumé rapide :

La séance portait sur les deux premiers chapitres de Refactoring de Martin Fowler, qu’on ne présente plus

Couverture du livre

La discussion a commencé sur la difficulté de faire du Refactoring en partie à cause d’une vision biaisée que le monde du business logiciel lui donne. Fowler explique à ce titre que le Refactoring n’est pas une tâche à part entière mais plutôt une étape de chaque développement. On aura paraphrasé Kent Beck :

To make a change, make the change easy and then make an easy change.

L’excuse “on a pas le temps on verra lors de la prochaine refacto” est un non sens financièrement parlant puisqu’une dette technique est quasi toujours mal maitrisée. Certes, certaines entreprises ont besoin d’une petite dette technique pour bien fonctionner, mais souvent la dette s’accumule et la période de refacto apparaît de plus en plus imaginaire

Quand refacto et quand ne pas refacto du coup ?

If it ain’t broke, don’t fix it

Ne pas aller refacto du code quand on sait que le code ne va pas évoluer. Le mieux est donc de refacto pour chaque feature donnée mais ça je vous en ai déjà parlé

On a évoqué l’importance du code review et des habitudes de chacun pour paraitre diplomatique dans les remarques. L’étape de la revue de code, ou celle du cross testing (qu’on fait peu ici), est également une bonne étape pour faire du refacto

En outre, la force des tests, c’est qu’ils permettent que le processus de refactoring soit sans régression.

Mais aussi : c’est difficile d’être un génie et de voir les patterns émerger sur du code legacy. Une bonne solution c’est de faire des tests pour faire émerger le “Quoi?” plutôt que le “Comment?”. Le quoi désigne le besoin utilisateur (dans tel contexte, je fais telle action, je m’attends à tel résultat). Le comment désigne l’implémentation. Pour chaque test qu’on veut créer on se rend compte qu’on ne peut pas tester en l’état actuel des choses (besoin de mocker 100 objets par exemple) et alors on fait un petit refacto. Quand s’arrêter ? C’est l’objet du chapitre 3 !

Prochaine session : http://www.meetup.com/Software-Craftsmanship-Lyon/events/227528781

 

Pourquoi sommes nous passés à Typescript ?

Il y’a quelques mois, nous avons migré notre frontend (4/5 applications Angular.JS, et pas des plus petites) en ES6 alias ES2015 (de façon incrémentale grâce à un workflow mi ES5, mi ES6). Je ne vous apprends rien du gain en maintenabilité et confort au niveau développement que ça nous as apporté. Hors avec le bond en popularité qu’est en train d’acquérir Typescript (Angular2 ne doit pas y être étranger), nous nous sommes posés la question du passage à Typescript.
… 

 

Workflow ES6 au sein d’une application Angular existante ES5

ECMAScript 6 (alias spécification de la future version de Javascript) se rapproche de plus en plus d’une version finale. De nombreux outils permettent déjà d’utiliser la syntaxe et les fonctionnalités d’ES6 avec du code généré compatible avec les navigateurs récents (et même un peu plus vieux). Et donc afin de limiter au maximum la dette technique au sein de nos applications, nous pensons que le changement, c’est maintenant.
… 

 

PMSIpilot UI, le thème bootstrap made in PMSIpilot

Chez PMSIpilot, nous développons une multitude d’applications web, que ce soit pour nos clients, ou pour des outils internes. Et pour chaque application, nous sommes confrontés à la problématique du design, de la cohérence par rapport aux autres applications. L’idée d’avoir une base commune s’est donc rapidement imposée.

… 

 

Agile Barcamp Lyon : Kanban

Je connais la méthode Scrum, pour en pratiquer une partie dans mon équipe, et j’étais intéressée par l’approche Kanban, qui n’est pas itérative avec des sprints isolés comme Scrum, mais qui prend en compte les arrivées en cours de route (les bugs, par exemple) et permet de les intégrer au flux. (Nous traitons ces demandes entrantes dans nos sprints en utilisant la focalisation.) De plus, mon envie de découvrir Kanban a été récemment augmentée, surtout à travers un retour d’expérience, car je suis passée à un travail de maintenance qui peut se faire sans sprint.
…