REX : Jenkins Community Day, Paris 11/07/2017

Zoubeyda ZARKOUNA
Aug 27, 2017 · 4 min read

Le premier “Jenkins Community Day” Paris s’est tenu à la Grande Crypte mardi 11 juillet dernier.

J’ y étais afin de profiter des retours de la communauté sur les usages de Jenkins et pour en savoir plus sur l’avenir du projet, l’évenement a été inauguré par Kohsuke Kawaguchi, créateur de Jenkins et CTO de CloudBees.

Dans cet article, je ne vais pas suivre le plan de «Jenkins Community Day» mais je vais partager avec vous ce qui me semble le plus pertinent.

JFrog vous accueille..

les grenouilles nous ont présenté les outils JFrog et principalement le plugin jenkins pour artifactory.
Vous trouvez ci dessous un schéma, représentant les outils jFrog:

https://www.jfrog.com/support-service/whitepapers/comparing-artifactory-to-other-binary-repository-managers/
  • Artifactory: un référentiel d’artéfacts (artifact manager): “development time tool”.
  • Bintray: un référentiel d’artéfacts (artifact manager): “release and destribution time tool”.
  • Mission Control: un gestionnaire des permissions (qui a accès à quoi?).
  • Xray: un outil qui permet d’analyser les artéfacts.
  • Plugin jenkins: un plugin qui permet de publier l’artéfact ainsi qu’envoyer les informations de build à Artifactory.

The future of jenkins, jenkins aujourd’hui et demain ..

Kohsuke Kawaguchi nous a présenté l’importance du changement culturel afin de réduire le «time to market» et il a évoqué deux exemples:

  • Amazon «Amazon is on record as making changes to production every ~ 11.6 seconds».
  • Tesla, les voitures sont mises à jour via OTA(Over-the-air programming).

Puis il a présenté le contexte de la chaine d’intégration/déploiement continue ainsi que les principales nouvelles “features” de jenkins.

  • La sécurité: la sécurité est un axe très important, on remarque une refonte sur les dernières release de jenkins. De plus, avec l’apparition des pipelines, le “script approval” a été ajouté afin de valider les nouveaux scripts “groovy” par un administrateur jenkins!
  • Pipeline: (ex workflow), cela permet de déclarer la configuration du job dans le même dépôt “scm”, ce qui évite d’avoir de l’intelligence dans jenkins et par conséquent ce dernier ne fait que créer le job en se basant sur un fichier “groovy”.
  • Shared library: Cela permet de partager les fonctions/les variables utilisées par plusieurs projets (on peut choisir la version de la librairie dans la configuration globale de jenkins et on peut surcharger la valeur dans le jenkinsfile).
  • Blue Ocean: La refonte graphique de l’interface, une “UI sexy” de jenkins!

Aujourd’hui, il faut noter:

  • Qu’un changement de culture est inévitable, «build fast», «fail fast», pour réduire le «time to market».
  • Qu’il y a une documentation détaillée et à jour de la pipeline de jenkins ce qui la rend facile d’utilisation.
  • Que la communauté est focalisée sur l’aspect sécurité de jenkins.

Le CI/CD pipeline pour ses clients d’API

Ce talk a été présenté par “clever cloud”, une solution de PAAS européenne.
Ce qui a attiré mon attention c’est la solution “reverse” proxy appelée Sōzu, dont l’objectif est de ne pas mettre de l’intelligence dans le “reverse” proxy.
Contrairement à Traefik, Sōzu ne cherche pas directement l’information, mais il expose un “channel” de communication.
On peut, alors, développer un outil moyennant un langage au choix afin de permettre la communication entre le “backend” de configuration et le « reverse » proxy.
Vous trouvez plus d’informations sur le blog de “clever cloud”.

« Scale »Jenkins sur Google Cloud

Pour ce talk, “Guillaume Laforge”, nous a présenté le contexte comme suit :
il s’agit du cas d’un projet où on a plusieurs commits par jour et une chaine d’intégration continue.
Créer un slave jenkins à la demande (dans lequel le build sera exécuté et qui sera supprimé juste après), va nous permettre de gagner en resource et en performance.
En effet, il est inutile d’avoir un slave jenkins “up” et “running” en attente d’un build.

Pour plus d’informations, vous trouvez le lien vers la présentation, le lien github du projet ainsi que le lien vers le plugin kubernetes de jenkins.

Automatiser sa chaîne Devops avec Jenkins et JHipster

Concernant la partie déploiement continue, “Denis Floch” s’est focalisé sur:

  • l’utilisation des pipelines.
  • la creation d’un jenkinsfile par dépôt.
  • l’utilisation des “shared libraries” afin de centraliser les fonctions communes, ceci permet d’enrichir le DSL, faciliter la maintenance et éviter les contraintes de la sandbox!

Pour plus d’informations, vous trouvez ici les étapes du projet.

Quali

Durant la pause, j’ai rencontré un représentant de “Quali”, une entreprise spécialisée dans le développement des outils d’automatisation du devops “lifecycle”.
j’ai assisté à une démo décrivant l’interaction entre la solution CI/CD de Quali et Jenkins.
Une solution permettant:

  • de déployer à chaque étape de build un environnement complet ”~ISO prod” (sur une infrastructure au choix, physique, virtuelle ou cloud).
  • d’exécuter les tests de validation.
  • de passer à l’étape suivante en cas de succès.

Pour plus de détails vous trouvez un lien vers la solution CI/CD de Quali, un lien vers la démo, et un lien vers le plugin jenkins.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade