Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.

Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.

En cas de performance limitée par les IOPS EBS, il y a 3 solutions:

• augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
• passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
• utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)

Présentation des pipelines de Jenkins 2.
À noter quelques étapes supplémentaires dans le contexte de microservices:

• utilisation d'une release pipeline pour coordonner le déploiement en prod de plusieurs microservices interdépendants
• création d'un artifact manifest lors du build qui recense les versions des différents services
• identification des versions actuellement utilisées en prod et création d'un artifact update qui recense les versions à mettre à jour (diff entre le manifest et la prod)

Un exemple de pipeline avec Openshift et un Jenkins embarqué

Un tuto pour utiliser les nouvelles fonctionnalités de pipeline de Jenkins 2 avec une application NPM Electron

Dans la 3ème partie, l'article explique comment Taurus permet d'automatiser l’exécution de tests de performances dans un contexte d'intégration continue en permettant l'éxecution de commandes shell (module shellexec) avant ou après le test et la collection de métriques de monitoring (module monitoring et agent ServerAgent)

Best Practices pour utiliser les pipelines avec Jenkins 2.0

A performance budget is just what it sounds like: you set a “budget” on your page and do not allow the page to exceed that. This may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or size of the page.
(...)
Once those goals are set, you stick to them. Anytime you want to add something to a page, you need to ensure it stays within budget. Steve Souders talked about the three options you have if something does not fit within the budget:

1. Optimize an existing feature or asset on the page.
2. Remove an existing feature or asset from the page.
3. Don’t add the new feature or asset.

Le budget performance correspond à la valeur max autorisée pour une métrique de performance (temps de chargement, nombre de requêtes ou poids de la page). On peut ensuite tester le "budget" au cours de l'intégration continue avec un outils comme SiteSpeed.io et remonter une alerte en cas de dépassement.

How-to pour mettre en place un Slave Jenkins sur un Mac pour builder des apps IOS depuis le Jenkins Master

1er article d'une série qui propose une alternative plus simple/fiable/rapide au Maven Release Plugin de Jenkins pour créer une nouvelle release Maven.

https://axelfontaine.com/blog/maven-releases-steroids-2.html
https://axelfontaine.com/blog/maven-releases-steroids-3.html
https://axelfontaine.com/blog/final-nail.html

Un repository de scripts Groovy pour administrer Jenkins.
Pour gérer ces scripts depuis Jenkins, il faut installer Scriptler Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Scriptler+Plugin)

Job DSL plugin permet de definir la configuration des jobs Jenkins a l'aide de scripts groovy versionnables

J'utilise copyartifact plugin pour ca. Si tu as un repos maven accessible en http (ex: nexus ou artifactory) l'idéal etant que ton job de build maven publie l'artifact sur le repo maven et que le job de build docker le recupere depuis le repo maven

Une presentation de Multibranch Workflow Plugin qui permet de génerer dynamiquement un deployment pipeline pour toutes les branches d'un repo git à l'aide d'un Jenkinsfile intégré au repo git

L'article explique les pratiques de l'intégration continue et fourni un set de dockerfiles permettant de démarrer une stack CI complète avec Jenkins, Nexus, Sonarqube, Gitlab et 2 nodes Selenium (FF et Chrome) pour les tests UI.

Les dockerfiles sont ici: https://github.com/marcelbirkner/docker-ci-tool-stack

CloudBees Docker Hub Notification Plugin permet automatiser le déclenchement de jobs jenkins à chaque fois qu'une image docker est modifiée (ex: relancer le build et le test des applis à chaque fois qu'on applique les mis à jours de sécurité sur l'image docker base)

Pour permettre à un container de créer et démarrer d'autres containers (ex: CI/CD avec Jenkins dans un container qui créérais lui même d'autres containers dans ses builds), il suffit d'exporter le binaire docker et la socket docker:

-v /var/run/docker.sock:/var/run/docker.sock
-v $(which docker):/bin/docker

Un tuto pour automatiser la création et le déploiement d'images docker dans GoogleCloud avec Jenkins, Packer et Kubernetes

Le contenu du tuto (dockerfiles...) est disponible sur github: https://github.com/GoogleCloudPlatform/kube-jenkins-imager

Cas d'utilisation de Docker et Jenkins pour créer un CD Pipeline

Une explication du concept de Deployment Pipeline et de son implémentation dans Snap CI

Un exemple d'utilisation de docker pour automatiser des tests unitaires et d'intégrations avec maven/jenkins et selenium