Au sein d’une démarche DevOps, le build et le déploiement continue sont les premiers piliers à mettre en place. Cette session avancé de notre NighClazz “Build Tools & Continuous Delivery” a pour objectif de présenter les modes de déploiement "Blue-Green Deployment" et "Feature toggle" ainsi que les principes d'automatisation des schémas de base de données.

1. NightClazz Avancée
BuildTools &
Continuous Delivery

2. NCBuildToolsContinuousDeliveryAvanced_v2 2
Quelques mots sur nous
1) Grégory Boissinot (@gboissinot)
– Continuous Integration, Continuous Delivery and Jenkins Addict
– Zenika Paris CTO
2) Khaled Souf (@khaledsouf)
– Consultant et Formateur Zenika
– Expérienceen Intégration Continue
3) Julien Aubin
– Consultant Zenika
– Sa dernière mission DevOps

3. NCBuildToolsContinuousDeliveryAvanced_v2 3
Programme
1) Principes de l'intégration continue et du continuous delivery (rappel)
2) Modes de déploiement
– Le mode "Blue-Green Deployment"
– Le mode "Toggle Feature"
3) La gestion des dépendances dans le monde Java pour le build
– Les différents cas d'usages
– La gestion de dépendances sous maven et gradle
4) Automatisation Migration des données
– principe d'automatisation des schémas de base de données
– Pour Java et Spring, exemple d'outils : Flyway et Liquibase
– Workshop Flyway et Liquibase avec Gradle et Maven

4. NCBuildToolsContinuousDeliveryAvanced_v2 4
Plan
1) Principes de l'intégration continue et du continuous delivery (rappel)
2) Modes de déploiement
– Le mode "Blue-Green Deployment"
– Le mode "Toggle Feature"
3) La gestion des dépendances dans le monde Java pour le build
– Les différents cas d'usages
– La gestion de dépendances sous maven et gradle
4) Automatisation Migration des données
– principe d'automatisation des schémas de base de données
– Pour Java et Spring, exemple d'outils : Flyway et Liquibase
– Workshop Flyway et Liquibase avec Gradle et Maven

5. NCBuildToolsContinuousDeliveryAvanced_v2 5
L'idéal : Livrer fréquemment
Feedback
Develop
Test
Deploy
Monitor
Cycle de livraison
avec un retour rapide des utilisateurs
Dev
Ops
→ Réduction du Time-to-
Market
→ Réduction du coût de
correction des erreurs

6. NCBuildToolsContinuousDeliveryAvanced_v2 6
La livraison logicielle
(Release)
●
Avoir un processus répétable et fiable pour la livraison logicielle
– Automatiser un maximum d'éléments
– Intervention humaine pour des fonctions à hautes valeurs ajoutés
●
Test, validation et promotion (manuelle)
DEPLOY
INSTALL
RELEASE
BUILD
UNIT TESTS
TEST
VALIDATION
Processus identifié (traçabilité) et reproductible (fiabilité) Visibilité
&
Feedback
Vérification
Ensemble des étapes d'une livraison logicielle

7. NCBuildToolsContinuousDeliveryAvanced_v2 7
Continuous Integration
(CI)
●
Méthodologie agile consistant à construire et à tester le logiciel à chaque
changement de code source
SCM
Source code
Build scripts
BUILD
Compile
Unit Tests
Code analysis
Assemble
(package + installer)
Artifact
Repository
Binaries
Unit Test Reports
BuildContext
Metadata
OBJECTIF:
Garder le code source propre (clean) en détectant les erreurs de
développement au plus tôt
Créer une livraison logicielle éligible (release candidate)

8. NCBuildToolsContinuousDeliveryAvanced_v2 8
Continuous Delivery / Continuous Deployment
(CD)
●
Focaliser sur la mise à disposition et le déploiement d'un ensemble de
changements métier sur un ou plusieurs environnements
SCM
Deployment Scripts
Configuration Data
Artifact
Repository
Binaries
Artifact
Repository
Test results
metadata
DEPLOY & TEST
Configure Environment
(Provisioning)
Deploy
Test
Validate
Orchestration et gestion d'un
ensemble d'étapes
OBJECTIF:
Livrer plus rapidement de petites itérations à l'utilisateur
(extension du CI)

9. NCBuildToolsContinuousDeliveryAvanced_v2 9
Continuous Delivery et Fonctionnalités métiers
Flux constant de nouvelles fonctionnalités dans un environnement cible
Une livraison logicielle toujours prête à être utilisée par les
utilisateurs et contraintes uniquement par les besoins métiers
(non pas par les contraintes opérationnelles)
User
Equipe
Logicielle

10. NCBuildToolsContinuousDeliveryAvanced_v2 10
Continuous Delivery
Exemple de Pipelining
START
TOMCAT
Provisining
Tomcat
ACCEPTANCE
TEST
VALIDATION
INJECT
TEST DATA
Constitution d'un workflow : ensemble d'étapes
Possibilité de paralléliser certaines étapes
Objectifs: Cartographie, Visibilité, Reprise sur erreur
Exemple de Pipeline du test d'une application Web sous Tomcat
PERFORMANCE
TEST
STOP
TOMCAT
EXPLORATING
TEST
Etape
Manuelle

11. NCBuildToolsContinuousDeliveryAvanced_v2 11
Déploiement & Environnement Applicatif
TEST PRODUCTION
Automated Lifecycle
Automated
Provisioning
Plusieurs environnements possibles
Infrastructure Physique, Virtuelle ou Cloud
Chaque environnement doit être le plus proche de la production
(Gestion des configurations par environnement)
Le provisioning doit améliorer la fiabilité du déploiement

12. NCBuildToolsContinuousDeliveryAvanced_v2 12
Blue Green Deployment
●
Problématique
➢
Déploiements longs à effectuer
➢
Downtime souvent conséquent, parfois plusieurs heures
➢
Si bug majeur, souvent difficulté conséquente à faire un rollback
➢
Solution : duplication de la chaine de production
●
Principe
➢
Deux chaînes de production aussi identiques que possible
➢
L'une contient la nouvelle version du logiciel, l'autre l'ancienne
➢
Au moment du déploiement on effectue la bascule par
l'intermédiaire d'un routeur

13. NCBuildToolsContinuousDeliveryAvanced_v2 13
Blue Green Deployment
Utilisateurs Routeur
Serveur Web Serveur Applicatif DB
Blue Blue Blue
Green GreenGreen

14. NCBuildToolsContinuousDeliveryAvanced_v2 14
Blue Green Deployment - Inconvénients
●
Dédoublement du matériel
●
Plus de maintenance système à faire
●
Garder une compatibilité ascendante de la gestion de données pour pouv
faire un rollback sans douleur

15. NCBuildToolsContinuousDeliveryAvanced_v2 15
Toggle feature
●
Problématique
●
Gestion de différents ensembles de fonctionnalités pour différents utilisateurs
●
Solution classique : une branche de développement par groupe d'utilisateurs
●
Problème : intégration des différents correctifs et features communes dans
les différentes branches
●
Principe
●
Implémenter un système pour activer ou désactiver des fonctionnalités
(toggle)
●
Possibilité de faire des déploiements avec des fonctionnalités non terminées
ou non testées (désactivées)
●
Maintenance du code plus facile

16. NCBuildToolsContinuousDeliveryAvanced_v2 16
Toggle feature
Quelques librairies de Toggle Feature
●
Java : togglz -http://www.togglz.org/
●
Java / Spring : ff4j -http://ff4j.org/
●
.Net : NFeature (ressemble à togglz pour Java) -
https://github.com/benaston/NFeature

17. NCBuildToolsContinuousDeliveryAvanced_v2 17
Toggle feature – exemple de code avec togglz
if( MyFeatures.FEATURE_ONE.isActive() ) {
// new stuff here
}

18. NCBuildToolsContinuousDeliveryAvanced_v2 18
L'étape du build
dans la livraison logicielle
PackageBinariesSource
Unit Test
Analysis
Model
DEPLOY
INSTALL
LIVRAISON
TEST
VALIDATION
Build
Generate
Packaging
Quality
BUILD
UNIT TEST

19. NCBuildToolsContinuousDeliveryAvanced_v2 19
Gestion de Dépendances
●
Avez-vous besoin d'encapsuler toutes vos dépendances dans vos livrables ?
– Des dépendances existent-elles déjà sur votre serveur de déploiment ?
– Vous avez besoin de vos dépendances sous quelle forme (sources, binaires) ?
– Vous en avez besoin à quel moment ? (compilation, exécution, test )
→ Portée et type de dépendances
●
Vos dépendances ont-elles besoin de toutes leur dépendances à leur tour ?
– Avez vous vérifié que vos dépendances ne remontent pas des versions différentes d'une
même sous-dépendance ?
– Avez vous mis en place une action pour ne plus avoir ce genre de problème ?
→ Transitivité

20. NCBuildToolsContinuousDeliveryAvanced_v2 20
Portée des dépendances avec maven
●
Compile : scope par défaut inclus dans la classpath du projet et aussi propagé
pour les projets dépendants.
●
Exemples: spring-core, eclipselink ...
●
Provided: fourni par l'environnement (JDK ou Conteneur …)
●
Exemples : JDBC driver, lombok, ...
●
Runtime : requis pour l'exécution mais pas à la compilation.
●
Exemples : jcl-over-slf4j
●
Test: requis pour les tests uniquement.
●
Exemples : JUnit, AssertJ, ...
●
System : similaire à provided sauf que le chemin de la dépendance doit être
fourni.
●
Import : dépendance de type “pom”

21. NCBuildToolsContinuousDeliveryAvanced_v2 21
Transitivité des dépendances avec maven
●
Problématique : A dépend de D en version 2.0 et A dépend de B qui lui-même
dépend de D en version 1.0.
●
Aurons-nous les deux versions de D dans A ?
●
Si ce n'est pas le cas comment Maven fait-il sont choix ?
●
Pouvons-nous exclure les dépendances transitives indésirables ?
●
Solutions envisageables :
●
Maven (à partir de la version 2.0.9) joue le médiateur et fait le choix selon la
dépendance la plus proche (dans notre cas c'est la version 2.0 qui gagne)
●
Les exclusions : exclure au niveau du projet A la dépendance D du projet B.
●
Dépendance Optionnelle : marquer la dépendance D au niveau de B
comme étant une dépendance optionnelle.

22. NCBuildToolsContinuousDeliveryAvanced_v2 22
Déclaration des dépendances avec Maven
<project>
….
<dependencies>
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongo-java-driver</artifactId>
<scope>test<scope>
<version>2.11.4</version>
<exclusions>
<exclusion>
<groupId>com.github.fakemongo</groupId>
<artifactId>fongo</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>

23. NCBuildToolsContinuousDeliveryAvanced_v2 23
Le Plugin Dependency de Maven
●
Permet de vérifier la portée de vos dépendances
●
Permet d'afficher tout l'arbre de dépendances déclarées et non
déclarées avec leur portées respectives.
●
Permet dedétecterles conflits de dépendances.
●
Offre aussi d'autres fonctionnalités telles que la copie des dépendances

24. NCBuildToolsContinuousDeliveryAvanced_v2 24
Portée des dépendances avec Gradle
●
compile: incluses dans la classpath du projet et aussipropagées
pour les projets dépendants.
●
runtime: scope par défaut requis pour l'exécution mais pas à la
compilation.
●
testCompile: requis pour la compilation des tests.
●
testRuntime: requis pour l'exécution des tests.
Vous pouvez aussi définir votre propre scope.

25. NCBuildToolsContinuousDeliveryAvanced_v2 25
Déclaration des Dépendances avec Gradle
apply plugin: 'java'
repositories {
mavenCentral()
}
dependencies {
compile "org.slf4j:slf4j-log4j12:1.7.5"
compile "org.slf4j:jul-to-slf4j:1.7.5"
testCompile group: 'junit', name: 'junit', version: '4.+'
}

26. NCBuildToolsContinuousDeliveryAvanced_v2 26
Plugin dependencies de Gradle
●
Similaire à maven dependency
●
Permet d'afficher tout l'arbre de dépendances.
●
Permet de filtrer par “task” et par module Gradle
●
Pour plus de détails on utilisedependencyInsightpour avoir des
informations sur une certaine dépendance, sa portée, ...

27. NCBuildToolsContinuousDeliveryAvanced_v2 27
PAUSE
PIZZA

28. NCBuildToolsContinuousDeliveryAvanced_v2 28
Déploiement - livrables
●
Sous quel format est livrée votre application (artifact, war, jar, dossie
●
Qui préconise le format de vos livrables ?
●
Y-a-t'il des plugins qui permettent de le faire ?

29. NCBuildToolsContinuousDeliveryAvanced_v2 29
Migration des Données
●
Avez-vous besoin de modifier votre modèle de données avant de
livrer ?
●
Avez vous besoin de cela de façon automatique ?

30. NCBuildToolsContinuousDeliveryAvanced_v2 30
Flyway
●
Framework de migration de bases de données
http://www.flywaydb.org
●
Migrations incrémentales (i.e. de V2 vers V5 par exemple)
●
Validation des versions de scripts avant lancement.
●
Supporte les scripts SQL pour des migrations simples ou Java pour d
migrations plus complexes
●
Ne couvre que les SGBD SQL
●
Extensible

31. NCBuildToolsContinuousDeliveryAvanced_v2 31
Flyway - Avantages
●
Analyse l'état de la base pour faire sa mise à jour (à partir d'un champ
de version), et pas de mise à jour à partir de données stockées en
dehors de la base.
●
Possibilité de migrer d'un coup un grand nombre de serveurs de
manière automatisée.
●
Très facile à invoquer, et de différentes manières (Maven, Spring, …)
●
Possibilité de tester les scripts avec des tests d'intégration (avec flyw
extensions)

32. NCBuildToolsContinuousDeliveryAvanced_v2 32
Flyway- Inconvénients
●
Nécessite un haut niveau de confiance dans les scripts de migration
●
Obligation de faire des dry-runs sur des données de production avant
de faire pour de bon les modifications (problème de récupération des
données)
●
Pas possible de mixer migrations via Flyway et migrations sans Flywa
(ou alors il faut penser à mettre à jour le champ de version de Flyway
●
Pas possible de revenir à une version antérieure de la base (mais il y
une bonne raison pour ça : cf. les DROP de requêtes et autres, cf. la
FAQ de Flyway)
●
Pas d'abstraction des scripts SQL par rapport au SGBD.

33. NCBuildToolsContinuousDeliveryAvanced_v2 33
TRAVAUX
PRATIQUES

34. NCBuildToolsContinuousDeliveryAvanced_v2 34
Liquibase
●
Framework de migration de bases de données
●
http://www.liquibase.org/
●
Les changements sont sous forme de fichier XML sauf que la migratio
elle même peut être faite en SQL, YAML, XML …
●
Un seul fichier est maintenu en entrée
●
Les versions concernent les “changes set”
●
Possibilitéde fournir un rollback pour chaque “change set”.

35. NCBuildToolsContinuousDeliveryAvanced_v2 35
Liquibase - Avantages
●
Fait abstraction du SGBD (dans le cas d'utilisation d'une migration
autre que SQL)
●
Possibilitéde revenir sur une version antérieure (sous réserve de
fournir le script rollback correspondant).
●
Très facile à invoquer, et de différentes manières (Maven, Spring, ...)

36. NCBuildToolsContinuousDeliveryAvanced_v2 36
Liquibase - Inconvénients
●
Ne se limite qu'à des opérations basiques au niveau des SGBD (pas
procédure stockée, de trigger ou même de package PL/SQL)
●
Utilisation fastidieuse du XML demandant certains concepts de
Liquibase pour faire un script de migration

37. NCBuildToolsContinuousDeliveryAvanced_v2 37
TRAVAUX
PRATIQUES