NightClazz Build Tools & Continuous Delivery

4,066 views
3,920 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,066
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

NightClazz Build Tools & Continuous Delivery

  1. 1. NightClazz Découverte BuildTools & Continuous Delivery #nightclazz
  2. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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. 12. 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. 13. 13 Le mouvement DevOps Culture Automatisation Mesure Collaboration
  14. 14. 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. 15. 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. 16. 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. 17. 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
  18. 18. 18 Java Build Tools
  19. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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. 26. 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. 27. 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. 28. 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. 29. 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. 30. 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' } }
  31. 31. 31 TRAVAUX PRATIQUES
  32. 32. 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. 33. 33 PAUSE
  34. 34. 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. 35. 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. 36. 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. 37. 37 Octopus en images
  38. 38. 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. 39. 39 XLDeploy en image
  40. 40. 40 Jenkins et son écosystème de plugins > Build Pipeline Plugin
  41. 41. 41 Jenkins et son écosystème de plugins > Delivery Pipeline Plugin
  42. 42. 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
  43. 43. 44 MaestroDev en Image
  44. 44. 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
  45. 45. 46 GO / Images
  46. 46. 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)
  47. 47. 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
  48. 48. 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
  49. 49. 50 Travaux Pratiques avec GO

×