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





– 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)

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











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











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

https://octopusdeploy.com/

http://www.xebialabs.com/products/xl-deploy

http://inedo.com/buildmaster

http://www.maestrodev.com/

http://www.thoughtworks.com/products/go-continuous-delivery

http://zeroturnaround.com/software/liverebel/

http://www.ca.com/us/products/detail/ca-lisa-release-automation.aspx

http://www.electric-cloud.com/solutions/continuous-delivery.php

http://www.midvision.com/products/rapiddeploy/

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

https://demo.octopusdeploy.com/

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

Technology

NightClazz Build Tools & Continuous Delivery