NightClazz Build Tools & Continuous Delivery

NightClazz Découverte
BuildTools &
Continuous Delivery
#nightclazz

2
Quelques mots sur nous
●
Grégory Boissinot (@gboissinot)
– Continuous Integration, Continuous Delivery and Jenkins Addict
– Zenika Paris CTO
●
Maxence Labusquière
– Etudiant en dernière année à l'ESIEA
– Stagiaire DevOps
●
Khaled Souf
– Consultant et Formateur Zenika
– Grosse expérience en Intégration Continue
●
Nassima Armouche
– Consultante et Formatrice Zenika
– Experte en Usine Logicielle
●
Julien Aubin
– Consultant Zenika
– Sa dernière mission: DevOps

3
Le programme
1) Problématique et enjeux de la construction logicielle, de l’intégration continue et du continuous
delivery
2) Focus sur les outils de build dans le monde Java et les outils de l’intégration continue
– Présentation des différents outils et critères de choix
– Serveur d'intégration continue Jenkins et Repository manager, etc
– Le mécanisme de livraison logicielle puis déclination avec Maven et Gradle
– Workshop : Faire une release avec Git & Maven
3) Le déploiement applicatif
– Problématiques et enjeux
– Présentation des principaux outils du marché : avantages, inconvénients
– Workshop avec le produit Thoughtworks GO

4
Plan
1) Problématique et enjeux de la construction logicielle, de l’intégration continue et du
continuous delivery
– Le mécanisme de livraison logicielle et déclination avec Maven et Gradle
– Workshop : Faire une release avec Git/Maven/Jenkins

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
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
Continuous Integration
(CI)
●
Méthodologie agile consistant à construire et à tester le logiciel à chaque
changement de 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
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
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
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
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
Configuration d'environnement
●
Configuration à la main
– Adapté à chaque besoin
– Mais problématique de passage à l'échelle
●
Duplication
– Notion d'environnement identique
– Gain de temps à partir du deuxième déploiement
– Problème de gestion des changements et de l'adaptation des
paramètres
●
Gestion Centrale
– Contrôle centralisé avec partage du savoir
– Notion de vérification des promesses
– Attention à la complexité de certaines opérations et prendre en compte
la montée en comnpétences des ops

13
Le mouvement DevOps
Culture
Automatisation
Mesure
Collaboration

14
S'engager dans le Continuous Delivery ?
Les questions à se poser (1/2)
●
Avez-vous pensé aux impacts organisationnels?
– Avez-vous une équipe dédiée pour ce besoin?
– Avez-vous inclus les équipes métier et marketing?
– Est-ce que vos produits peuvent être dans un état livrable après l'ajout
de fonctionnalités?
– Quel est le délai entre une livraison logicielle d'une fonctionnalité et
son usage par les utilisateurs?
– Qui est responsable du support en production?
●
En cas de problème en production, combien de temps faut-il pour revenir
à un état stable?
●
Avez-vous identifié le coût technique d'un “déploiement push button”
depuis une version pour un environnement ciblé?

15
S'engager dans le Continuous Delivery ?
Les questions à se poser (2/2)
●
D'où viennent les initiatives du Continuous Delivery?
– Développeurs, QA/Testeurs, Métier, Managers, Ops, Autres
●
Quel est votre niveau de maturité sur les outils de développement et
d'intégration et vos équipes?
– Outil de gestion de configuration logicielle (Git, Svn, etc)
– Outil d'issue tracking (Jira, Mantis, Bugzilla, etc)
– Serveur d'intégration continue (Jenkins, etc)
– Système de gestion d'artefacts (Nexus, Artifactory, etc)
– Système de monitoring (Nagios, Nunin etc)
– Gestion de configuration d'infrastructure (CFEngine, Puppet, etc)
– Est-ce que tous vos changements (Environnement, Infrastructure,
définition de système) sont dans un système de contrôle de version?

16
Plan
continuous delivery

17
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
Java Build Tools – Critères de choix
1) Le besoin réel des équipes projet
– Portée du processus (Build, Packaging, Déploiement, etc)
– Intégration dans les IDE
– Connaissance et apprentissage
– Communauté et évolution
2) Personnalisation des comportements d'intégration
– Flexibilité de paramétrage (Filtre de propriétés, etc)
– Gestion de dépendances
– Ajout de comportements (listener/hooks, etc)
– Modification d'extensions existantes

20
ANT in Action
<project name="MyProject" basedir=".">
<description>simple example build file</description>
<property name="src" location="src"/>
<property name="build" location="build"/>
<target name="init">

<tstamp/>

<mkdir dir="${build}"/>
</target>
<target name="compile" depends="init" description="compile the source " >

<javac srcdir="${src}" destdir="${build}"/>
</target>
</project>

21
Apache Maven in Action
<project>
<groupId>com.zenika</groupId>
<artifactId>maven-versionresolver</artifactId>
<version>1.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>maven-versionresolver</name>
<description>Maven Version Resolver</description>
<scm />
<developers />
<dependencies>
<dependency>
<groupId>org.mongodb</groupId>
<artifactId>mongo-java-driver</artifactId>
<version>${mongo-java-driver.version}</version>
</dependency>
</dependencies>
</project>
→Un outil de build (builder)
→Un système de gestion
de dépendances
→Une métadonnée d'usage

22
Gradle in Action
subprojects {
apply plugin: 'java'
sourceCompatibility = 1.7
targetCompatibility = 1.7
repositories {
mavenCentral()
maven {
url "http://dl.bintray.com/synchrotron-soleil-ica/ci-artifacts"
}
}
}
project(':libmongo-pomgenerator') {
dependencies {
compile project(':libmongo-domainobjects')
compile project(':libmongo-utilities')
compile "org.slf4j:slf4j-log4j12:1.7.5"
compile "org.slf4j:jul-to-slf4j:1.7.5"
}
}

23
Choix des outils de build
BuildTools Avantages Inconvénients
→ Très grande flexibilité (Très bas
niveau et donc facilité d'intégration)
→ Très performant
→ Flexibilité de définition et de
résolution de dépendances avec Ivy
→ Très bonnes intégration de ANT
dans les IDE
→ A cheval entre script et description
de langage
→ Verbeux
→ Glue d'intégration entre ANT et Ivy
à faire manuellement
→ Une approche Convention over
Configuration
→ Sa simplicité d'usage pour des
projets standards Java et JEE
→ Son adoption en masse et comme
standard de métadonnée pour les
repository de librairies OSS
→ Son manque d'approche “brique
Lego”
→ Mélange des informations de
projet et des informations de build
→ Non distinction entre descripteur
de build et descripteur d'utilisation
→ Langage de build (API de build)
→ Les conventions de Maven et à la
demande
→ Délégation aux tâches ANT
→ Peut compléter une infra Ant/Ivy et
Maven
→ DSL Groovy (Discutable)
→ Axe d'amélioration dans
l'intégration dans les IDE

24
Packaging de l'application
●
Utiliser un format de package standard
– “OS Native Package” : RPM, DEB, MSI, etc
– Format Zip : ZIP, TAR, etc
●
Intégration des différents composants binaires et des resources pou
son environnement cible
●
Il doit être possible de surcharger les fichiers de configuration par
défaut

25
Serveur d'intégration continue
& Jenkins
●
Fonctionnalités majeures
– Surveillance de l'environnement d'infrastructure pour
déclencher un build (polling & trigger)
– Préparation de l'environnement de build
– Lancer les commandes d'exécution
– Mettre à disposition un ensemble de rapports
●
Jenkins
– Devenu le standard de facto
– > 800 plugins

26
Artifact Repository Manager
●
Fonctionnalités majeures
– Stockage des binaires (mécanisme de sépération de repository)
– Proxy vers des repository public
– Fonctionnalité de recherche
– Tâches d'administration (purge, etc)
●
De nombreux outils
– 3 principaux
– Majoritairement Maven-centric
(au moins initialement orienté Metadata Maven)

27
Release Maven
●
Le plugin maven-release plugin
– Bonnes pratiques et mise à jour du gestionnaire de sources via le
plugin scm
●
En deux étapes via les goals :
– release:prepare
– release:perform
●
Possibilité de s'arrêter à une phase du cycle de construction via l'option
“goals”
●
Intégration avec jenkins via le plugin M2Release
●
Release impossible si un plugin ou une dépendance utilisé(e) est en
version SNAPSHOT

28
Release Maven in Action
<build>
<plugins>
...
<plugin>
<artifactId>maven-release-plugin</artifactId>
</plugin>
...
</plugins>
</build>
mvn release:prepare release:perform -Dgoals=install -B

29
Release Gradle
●
Il existe plusieurs façons pour réaliser une release Gradle
– À partir de plugins tels que “gradle-release”
●
Fonctionnement similaire à “maven release”
●
Détection automatique du SCM utilisé
●
Possibilité d'utiliser des dépendances en snapshot
– À partir de scripts gradle
●
Créer ses propres “task” de release
– Task de vérification des versions des dépendances
Example : pas de dépendance en snapshot
●
Utilisation du plugin maven pour déployer l'artifact
●
Intégration avec Jenkins via le plugin gradle

30
Release Gradle in Action
apply from: "https://launchpad.net/gradle-release/trunk/1.0/+download/apply.groovy"
subprojects {
apply plugin: 'java'
...
Version = '1.0'
release {
project.setProperty("gradle.release.useAutomaticVersion", "true");
}
–---------------------------------------------------------------------------------------------------------------------------
apply plugin: 'release'
buildscript {
repositories {
mavenCentral()
maven { url "https://oss.sonatype.org/content/groups/public"}
}
dependencies {
classpath 'com.github.townsfolk:gradle-release:1.2'
}
}

32
Plan
continuous delivery

34
Le besoin d'un outil
pour le déploiement applicatif
●
Eviter les sources d'erreurs de déploiement manuel
●
Réduire les éléments chronophage
●
Assure la conformité de l'environnement cible suite aux prérequis
●
Besoin de scalabilité
●
Traçabilité totale des processus
●
Cartographie de l'état des applications dans les différents environnements et de
l'avancement des processus

35
Les différents outils d'orchestration
et de déploiement
●
Outils orientés “Déploiement applicatif”
– Octopus Deploy
https://octopusdeploy.com
– XLDeploy
http://www.xebialabs.com/products/xl-deploy
●
Outils orientés “Orchestration”
– Jenkins et son ensemble de plugins (solution artisanale)
– BuildMaster
http://inedo.com/buildmaster
– MaestroDev
http://www.maestrodev.com
– Go ThoughtWorks http://www.thoughtworks.com/products/go-continuous-delivery
●
D'autres outils (non testés)
– LiveRebel - http://zeroturnaround.com/software/liverebel/
– CA Lisa Release Automation -http://www.ca.com/us/products/detail/ca-lisa-release-automation.aspx
– Electric Cloud Delivery Solution - http://www.electric-cloud.com/solutions/continuous-delivery.php
– RapidDeploy - http://www.midvision.com/products/rapiddeploy/
– etc

36
Octopus
●
Déploiement automatique pour .NET
●
Déploiement focus
– Pas uniquement pipeline
●
Notion de projet/processus et d'étapes (step)
●
Notion avancée dans la gestion d'environnements
●
Cible NuGet feed
●
Propose une solution de packaging enrichi (OctoPack)
●
Démonstration en ligne : https://demo.octopusdeploy.com/
●
Une boite noire efficace mais intrusive

38
XLDeploy
●
Déploiement focus (Possibilité de pipeline)
●
Implémentation du UDM
●
Gestion automatisée du SQL
●
Multi-platforme
●
Gère la configuration par des dictionnaires
●
Utilise un format de package propriétaire (.dar)
●
Fait un différentiel pour optimiser le déploiement
●
CLI & GUI
●
Retour des logs au serveur
●
Outil “intelligent” qui impose ses méthodes

40
Jenkins et son écosystème de plugins
> Build Pipeline Plugin

41
Jenkins et son écosystème de plugins
> Delivery Pipeline Plugin

43
MaestroDev
●
Pardes experts Maven
●
Vocabulaire : projet, composition, tâche
●
Intégration avec de nombreux outils
●
Propose une bibliothèques de tâches
●
Sortie console
●
Mécanisme de plugins
●
Console centralisée pour lancer les différents outils nécessaires aux
process

45
Go
●
Produit édité par Thougthworks
●
Origine CruiseControl
●
Bientôt en OSS (Apache v2.0)
●
Agnostique aux outils
●
Vocabulaire: Pipeline, Stage, Job et Tâche
●
Définition d'environnement et de materials
●
Tout est configuration XML
●
Notion de templates
●
Intégration avec les différents bug trackers
●
Gestion de configuration sous Git
●
Mécanisme de plugins
●
Un orchestrateur proposant un canevas afin de forcer les bonnes pratiques

47
Les problèmes des produits actuels
●
De nombreux outils de déploiement et de release automation
– Peu d'OSS
– Souvent inadaptés ou peu extensibles
●
“Builder”
– Aucune gestion de libellés en dehors du pattern de version
– Non séparation entre les données de build et de gestion de projets
– Non distinction entre descripteur de build et descripteur de consommation
●
“Artifact Repository Manager”
– Pas de stockage agnostique au métadonnées des builders (Maven, Ivy, NuGet, RPM, etc)
●
“Release and Deployment Automation”
– Pas de brique d'intégration avec les outils actuels mais un outil de plus (ne facilite pas la
collaboration entre les équipes)

48
Notre vision
●
Le besoin d'une plateforme collaborative d'outils et de processus
– Simple d'usage
– Extensible (à base de points d'extension)
– Mécanisme de cartographie, de visibilité et de feedback
●
Avoir des outils de livraison (au sens de déploiement) non intrusifs
– Par exemple: mise à jour des BD doit rester hautement maîtrisée
●
Pouvoir maîtriser avec finesse les rollbacks et les livraisons incrémentales
●
Intégration et ajout de fonctionnalités aux outils existants (Builders, DM, CI Servers) pour les nouveaux
besoins
– Release management
– Provisioning automation
– Deployment automation
– Project management & Workflows

49
Pragmatic Continuous Delivery Tooling Kit
Derived
Object
Repository
API
Release ManagementDependency Manager
Build Automation
CI
Maven Ivy Custom ... Jenkins ...
Provising Automation
CFEngine ...
Deployment
Automation
Pipelining & UI
UI Building CLI
Notification
Mechanisms
Template
Engine
...
Binaries Metadata
Workflow
Dev Ops

NightClazz Build Tools & Continuous Delivery

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à NightClazz Build Tools & Continuous Delivery

Similaire à NightClazz Build Tools & Continuous Delivery (20)

Plus de Zenika

Plus de Zenika (20)

NightClazz Build Tools & Continuous Delivery