NightClazz Build Tools & Continuous Delivery Avancé

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érience en Intégration Continue

3) Julien Aubin

– Consultant Zenika

– Sa dernière mission DevOps


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


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


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


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)

DEPLOYINSTALL

RELEASEBUILD

UNIT TESTSTEST

VALIDATION

Processus identifié (traçabilité) et reproductible (fiabilité) Visibilité &

Feedback

Vérification

Ensemble des étapes d'une livraison logicielle


Continuous Integration (CI)

● Méthodologie agile consistant à construire et à tester le logiciel à chaquechangement de code source

SCMSource codeBuild scripts

BUILDCompile

Unit TestsCode analysis

Assemble (package + installer)

ArtifactRepository

BinariesUnit Test Reports

BuildContextMetadata

OBJECTIF: Garder le code source propre (clean) en détectant les erreurs de

développement au plus tôtCréer une livraison logicielle éligible (release candidate)


Continuous Delivery / Continuous Deployment(CD)

● Focaliser sur la mise à disposition et le déploiement d'un ensemble dechangements métier sur un ou plusieurs environnements

SCMDeployment ScriptsConfiguration Data

ArtifactRepository

Binaries

ArtifactRepository

Test resultsmetadata

DEPLOY & TESTConfigure Environment

(Provisioning)Deploy

TestValidate

Orchestration et gestion d'un ensemble d'étapes

OBJECTIF: Livrer plus rapidement de petites itérations à l'utilisateur

(extension du CI)


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


Continuous DeliveryExemple de Pipelining

STARTTOMCAT

ProvisiningTomcat

ACCEPTANCETEST

VALIDATION

INJECT TEST DATA

Constitution d'un workflow : ensemble d'étapesPossibilité de paralléliser certaines étapes

Objectifs: Cartographie, Visibilité, Reprise sur erreur

Exemple de Pipeline du test d'une application Web sous Tomcat

PERFORMANCETEST

STOP TOMCAT

EXPLORATINGTEST

EtapeManuelle


Déploiement & Environnement Applicatif

TEST PRODUCTION

Automated Lifecycle

AutomatedProvisioning

Plusieurs environnements possiblesInfrastructure 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


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


Blue Green Deployment

Utilisateurs Routeur

Serveur Web Serveur Applicatif DB

Blue Blue Blue

Green GreenGreen


Blue Green Deployment - Inconvénients

● Dédoublement du matériel

● P lus de maintenance système à fa ire

● Garder une compatibilité ascendante de la gestion de données pour pouvoir faire un rollback sans douleur


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 dansles 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


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

http://www.togglz.org/

http://ff4j.org/

https://github.com/benaston/NFeature


Toggle feature – exemple de code avec togglz

if( MyFeatures.FEATURE_ONE.isActive() ) {

// new stuff here

}


L'étape du build dans la livraison logicielle

PackageBinariesSource

Unit TestAnalysis

Model

DEPLOYINSTALL

LIVRAISONTEST

VALIDATION

Build

Generate

Packaging

Quality

BUILDUNIT TEST


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'unemême sous-dépendance ?

– Avez vous mis en place une action pour ne plus avoir ce genre de problème ?

→ Transitivité


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”


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êmedé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 ladé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.


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>


Le Plugin Dependency de Maven

● Permet de vérifier la portée de vos dép endances

● Permet d'afficher tout l'arbre de dépendances déclarées et nondéclarées avec leur portées respectives.

● Permet de détecter les conflits de dépendances.

● Offre aussi d'autres fo nctionnalités telles que la copie des dépenda nces s


Portée des dépendances avec Gradle

● comp ile : incluses dans la classpath du projet et aussi propagées pour les projets dépendants.

● runtime : scope par défaut requis pour l'exécution mais pas à lacompilation.

● testCompile: requis pour la compilation des tests.

● testRuntime : requis pour l'exécution des tests.

Vous pouvez aussi définir votre propre scope.


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.+'

}


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 utilise dependencyInsight pour avoir desinformations sur une certaine dépendance, sa portée, ...


PAUSEPIZZA


Déploiement - livrables

● Sous quel format est livrée votre application (artifact, war, jar, dossier)

● Qui préconise le format de vos livrables ?

● Y-a-t'il des plugins qui permettent de le faire ?


Migration des Données

● Avez-vous besoin de modifier votre modèle de données avant delivrer ?

● Avez vous besoin de cela de façon automatique ?


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 desmigrations plus complexes

● Ne couvre que les SGBD SQL

● Extensible

http://www.flywaydb.org/


Flyway - Avantages

● Analyse l'état de la base pour faire sa mise à jour (à partir d'un champde version), et pas de mise à jour à partir de données stockées endehors de la base.

● Possibilité de migrer d'un coup un grand nombre de serveurs demaniè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 flywayextensions)


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 avantde 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 Flyway(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 aune bonne raison pour ça : cf. les DROP de requêtes et autres, cf. laFAQ de Flyway)

● Pas d'abstraction des scripts SQL par rapport au SGBD.


TRAVAUX PRATIQUES


Liquibase

● Framework de migration de bases de données

● http://www.liquibase.org/

● Les changements sont sous forme de fichier XML sauf que la migrationelle 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”.

http://www.liquibase.org/


Liquibase - Avantages

● Fait abstraction du SGBD (dans le cas d'utilisation d'une migrationautre que SQL)

● Possibilité de revenir sur une version antérieure (sous réserve defournir le script rollback correspondant).

● Très facile à invoquer, et de différentes manières (Maven, Spring, ...)


Liquibase - Inconvénients

● Ne se limite qu'à des opérations basiques au niveau des SGBD (pas deprocédure stockée, de trigger ou même de package PL/SQL)

● Utilisation fastidieuse du XML demandant certains concepts deLiquibase pour faire un script de migration


TRAVAUX PRATIQUES

NightClazz Build Tools & Continuous Delivery Avancé

Technology

Transcript of NightClazz Build Tools & Continuous Delivery Avancé