NightClazz Avancée
BuildTools &
Continuous Delivery
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
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
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
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
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
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)
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)
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
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
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
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
NCBuildToolsContinuousDeliveryAvanced_v2 13
Blue Green Deployment
Utilisateurs Routeur
Serveur Web Serveur Applicatif DB
Blue Blue Blue
Green GreenGreen
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
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
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
NCBuildToolsContinuousDeliveryAvanced_v2 17
Toggle feature – exemple de code avec togglz
if( MyFeatures.FEATURE_ONE.isActive() ) {
// new stuff here
}
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
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é
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”
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.
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>
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
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.
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.+'
}
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, ...
NCBuildToolsContinuousDeliveryAvanced_v2 27
PAUSE
PIZZA
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 ?
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 ?
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
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)
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.
NCBuildToolsContinuousDeliveryAvanced_v2 33
TRAVAUX
PRATIQUES
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”.
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, ...)
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
NCBuildToolsContinuousDeliveryAvanced_v2 37
TRAVAUX
PRATIQUES

NightClazz Build Tools & Continuous Delivery Avancé

  • 1.
  • 2.
    NCBuildToolsContinuousDeliveryAvanced_v2 2 Quelques motssur 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) Principesde 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) Principesde 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 livraisonlogicielle (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éthodologieagile 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 Deliveryet 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 Exemplede 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 GreenDeployment ● 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 GreenDeployment Utilisateurs Routeur Serveur Web Serveur Applicatif DB Blue Blue Blue Green GreenGreen
  • 14.
    NCBuildToolsContinuousDeliveryAvanced_v2 14 Blue GreenDeployment - 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 ● Gestionde 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 Quelqueslibrairies 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 dubuild 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 deDé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 desdé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é desdé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 desdé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 PluginDependency 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 desdé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 desDé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 dependenciesde 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.
  • 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 desDonné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 demigration 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écessiteun 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.
  • 34.
    NCBuildToolsContinuousDeliveryAvanced_v2 34 Liquibase ● Framework demigration 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.