Un nouveau projet de la fondation Jenkins qui permet d'automatiser une chaîne complète de CI/CD, de la création du repo à la promotion en prod avec Jenkins et Kubernetes. L’intégration semble s’approcher de ce que propose OpenShift en la matière.

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é

Best Practices pour utiliser les pipelines avec Jenkins 2.0

La gestion des environnements ante-prod est source de coût, de perte de temps et de risques liés aux différences entre les environnements.

L'auteur propose de supprimer tous les environnements anteprod:

• les développeurs dev en local, et on déploie direct en prod avec des feature flags
• les nouvelles features sont activées uniquement pour la qa qui se fait donc sur la prod
• et quand c'est go on active pour tout le monde

Les feedbacks sont ici:
https://dzone.com/articles/staging-servers-are-dead

Pour gérer les releases Maven avec du Continuous Delivery, l'article propose de préparer la release à chaque build mais de pusher les tags uniquement si la pipeline de test est OK:

1. Do a local checkout in a detached head
2. Use the Maven release plugin to prepare a release with pushChanges=false (we are not going to push the release commits back to master) and preparationGoals=initialize (we don't care if the tag is bad as we will only push tags that are good)
3. Run your stages release through your test pipeline
4. When you are ready to push to production (or if you prefer when ready to push to testing) you push the tag and release the staging repository

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

Pipeline Plugin (ex Workflow Plugin) permet de générer des deployments pipeline dans Jenkins à l'aide de scripts Groovy

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)

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 livre blanc qui recense les bonnes pratiques des acteurs du web:
de la culture devops aux architectures big data/nosql en passant par le déploiement continu, l'organisation des équipes et la conception d'api ouvertes à l'extérieur

Pour le télécharger sans s'enregistrer: https://julien.mailleret.fr/pub/octo-les-geants-du-web.pdf

Comment tirer partie des fonctions d'AWS pour faire du Blue/Green Deployment:

1. Créer une nouvelle stack (green) avec l'application mise à jour identique à la stack de production (blue) (Si on utilise Amazon OpsWork, il est possible de directement cloner une stack)
2. Faire tous les tests nécessaires sur la nouvelle stack (green)
3. Quand tous est OK, utiliser Amazon Route53 (DNS AWS) pour rediriger le traffic de la stack blue vers la stack green (nécessite d'avoir un TTL le plus bas possible au niveau DNS, paramétrer le TTL à 60s sur Route53)

En bonus, il est possible d'utiliser la technique Canary Release:

• Route53 permet de faire du routage pondéré: on commence par rediriger seulement 10% du traffic sur la nouvelle stack, puis 20%, ...
  Cela permet de limiter le nombre de users impactés en cas de problème et de vérifier le comportement en charge de façon plus lissée dans le temps.
• Si les stack blue et green utilisent l'autoscaling, la stack blue va se réduire et la stack green grossir au fur et à mesure que le routage pondéré amènera plus d'utilisateurs sur la nouvelle stack.

Suite de l'article qui parle notamment des problématique de modification de schema BDD dans le cadre du Blue/Green Deployment:
https://medium.com/aws-activate-startup-blog/upgrades-without-tears-part-2-blue-green-deployment-step-by-step-on-aws-29c0ffe99c60?source=rss----dad75eb79ad5---4

Le Feature Flipping permet de livrer en production des fonctions désactivées qui pourront ensuite être activé pour tout ou partie des utilisateurs.

Les cas d'utilisation sont multiples:

• livraison en prod de fonctionnalités non terminées lorsque les développeurs commitent sur le trunk (best practices pour le continuous deployment)
• rollback plus rapide (en cas de bug sur une nouvelle fonctionnalité, il suffit de la désactiver sans relivrer)
• tests sur des sous-population (A/B testing)
• proposer des fonctionnalités payantes
• Passer en mode dégradé en cas de problèmes de perfs (en desactivant les fonctions - critique mais + gourmandes en ressources)

3 tips for DevOps teams:

• Try to go from commit to live in production automatically.
• Use feature flags or flippers instead of branching
• Run a bunch of really small production tests, performing real interactions with your live site, such as creating new user accounts, using Selenium, or just curling some URLs. Then add them to your deployment pipeline. If any of the tests fail, just deploy the old version.

Une synthèse des patterns utilisées pour déployer sans interruption de service dans un contexte de Continuous Deployment.