Pour assurer une mise à jour sans problèmes des logiciels, la plupart des banques, par exemple, utilise des outils de « continuous delivery » ( CD) afin d’éviter des bugs en suivant la mise en route de différentes versions. L’opération s’effecute en continu en les testant pour éviter les incompatibilités et les erreurs de mises à jour qui peuvent coûter des millions d’euros, en particulier dans les banques qui ont industrialisé les processus.
Rencontré dans le cadre du CD Summit, à Londres, Damien Coraboeuf connait bien ces problèmes de suivis d’applications. Il travaille en Belgique comme expert indépendant dans ce secteur depuis plus de 10 ans, et pour lui le phénomène de la vérification des applications avec des outils de CD comme Jenkins ne va que s’accentuer. « Je travaille avec des équipes qui ne peuvent pas toutes manipuler toutes les données. Avec notre contrôleur universel, on surveille les différents « pipelines » entre développeurs qui restent dans un cadre d’un protocole séccurisé et en cas de risques, même en pleine nuit on intervient. Chacun des développeurs ne doit pas savoir ce que font les autres, c’est un critère de sécurité lorsqu’on travaille dans les services bancaires. On est six chez « Click to pay » à superviser une quarantaine de développeurs. Sans le framework Jenkins cela serait très difficile à faire. Lors de sa présentation Damien Courtaboeuf détaillait l’utilisation de ses outils de validation.
« Dans notre organisation, nous avons donc un framework , qui est utilisé pour développer toutes sortes de produits. Ces produits sont eux-mêmes utilisés pour développer des projets de l’utilisateur final. La maintenance et le support sont nécessaires à chaque niveau de la livraison des programmes et nous utilisons les fonctions « branches » pour cela. Cela crée des centaines de combinaisons.
Maintenant, pour chaque produit ou du moins la dernière version du projet, que l’on appelle aussi branche en référence au tronc commun), nous avons un pipeline de livraison. Nous commençons par la compilation, les tests, l’emballage et l’édition. Ensuite, nous déployons la demande sur les différentes plates-formes prises en charge et passons par les différents niveaux de validation, jusqu’à ce que nous soyons prêts pour la livraison finale. Mis à part quelques détails et éléments de configuration, la plupart des pipelines sont identiques d’une branche à l’autre, d’un projet à l’autre.
Donc, un seul cadre, certains produits, plusieurs projets, des branches de maintenance, les pipelines complexes … Nous finissons par avoir dans Jenkins beaucoup de jobs à créer, à dupliquer et à entretenir. Avant même d’évoluer dans cette direction, nous avions vu cela comme un problème de blocage inévitable – il n’y avait aucun moyen à priori pour que nous puissions gérer manuellement des milliers de jobs au jour le jour.
La solution que nous recherchions devrait avoir les caractéristiques suivantes:
Self service – notre objectif étant de déléguer le travail et l’administration de branche dans Jenkins aux projets, afin de réduire le temps de soutien
Sécurité – nous ne voulions pas ouvrir Jenkins pour les projets au niveau de configuration – ce qui n’est pas acceptable dans notre contexte d’opérations bancaires
Simplicité – la solution doit être assez simple pour être gérable par des personnes non informées sur les technologies de base de Jenkins
Extensibilité – la solution doit être suffisamment souple pour permettre des extensions en cas de besoin
Lorsque nous avons pensé à l’aide du plug-in de script Dsl d’emploi de déléguer la création du pipeline pour les équipes de projet était OK à partir d’un point de vue de self-service, mais n’a pas été sécurisé et certainement pas simple pour les gens qui ne connaissent pas Jenkins.
puis