Upload
zenika
View
1.348
Download
1
Embed Size (px)
DESCRIPTION
Au sein d’une démarche DevOps, le build et le déploiement continue sont les premiers piliers à mettre en place. Cette session découverte de notre NighClazz “Build Tools & Continuous Delivery” a pour objectif de présenter les enjeux de l’automatisation, d’introduire les principaux outils de builds Java, de comprendre le mécanisme de livraison logicielle et de déploiement continue.
Citation preview
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
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 et déclination avec Maven et Gradle
– Workshop : Faire une release avec Git/Maven/Jenkins
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
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)
DEPLOYINSTALL
RELEASEBUILD
UNIT TESTSTEST
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
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)
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
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)
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 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
11
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
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
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 et déclination avec Maven et Gradle
– Workshop : Faire une release avec Git/Maven/Jenkins
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
17
L'étape du build dans la livraison logicielle
PackageBinariesSource
Unit TestAnalysis
Model
DEPLOYINSTALL
LIVRAISONTEST
VALIDATION
Build
Generate
Packaging
Quality
BUILDUNIT TEST
18
Java Build Tools
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"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target>
<target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <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 pour 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épendancesExample : 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' } }
$ gradle release
31
TRAVAUX PRATIQUES
32
Plan
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 et déclination avec Maven et Gradle
– Workshop : Faire une release avec Git/Maven/Jenkins
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
33
PAUSE
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'orchestrationet de déploiement
● Outils orientés “Déploiement applicatif”
– Octopus Deployhttps://octopusdeploy.com
– XLDeployhttp://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
37
Octopus en images
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
39
XLDeploy en image
40
Jenkins et son écosystème de plugins
> Build Pipeline Plugin
41
Jenkins et son écosystème de plugins
> Delivery Pipeline Plugin
43
MaestroDev
● Par des 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
44
MaestroDev en Image
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
46
GO / Images
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
DerivedObject
Repository
API
Release ManagementDependency Manager
Build Automation
CI
Maven Ivy Custom ... Jenkins ...
Provising Automation
CFEngine ...
Deployment Automation
Pipelining & UI
UI Building CLI NotificationMechanisms
Template Engine ...
Binaries Metadata
Workflow
Dev Ops
50
Travaux Pratiquesavec GO