Formation Usine Logicielle gratuite par Ippon 2014

Usine logicielle JavaL’industrialisation de la

mise en production

Licence

Cette formation vous est fournie sous licence Creative Commons AttributionNonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)

Vous êtes libres de :

Copier, distribuer et communiquer le matériel par tous moyens et sous tous formats

Selon les conditions suivantes :

● Attribution : Vous devez créditer l'Oeuvre, intégrer un lien vers la licence et indiquer si des modifications ont été effectuées à l'Oeuvre. Vous devez indiquer ces informations par tous les moyens possibles mais vous ne pouvez pas suggérer que l'Offrant vous soutient ou soutient la façon dont vous avez utilisé son Oeuvre.

● Pas d’Utilisation Commerciale : Vous n'êtes pas autoriser à faire un usage commercial de cette Oeuvre, tout ou partie du matériel la composant.

● Pas de modifications : Dans le cas où vous effectuez un remix, que vous transformez, ou créez à partir du matériel composant l'Oeuvre originale, vous n'êtes pas autorisé à distribuer ou mettre à disposition l'Oeuvre modifiée.

http://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr

Ippon Formation en bref

Pourquoi Ippon Technologies publie ses supports de formation ?

Car Ippon participe à la communauté Java et Web et soutien le modèle open-source

Le support théorique représente 40% du temps de formation, l'intérêt est dans les Travaux Pratiques et l'expert Ippon qui assure le cours

Pour nous contacter

Pour nous contacter et participer à nos formations :● Technique : formation@ippon.fr● Commercial : nzago@ippon.fr

Toutes les informations et les dates de formations sont sur notre site internet et notre blog:● http://www.ippon.fr/formation● http://blog.ippon.fr

Sommaire

● Introduction● Le déploiement logiciel

○ Approche naïve○ Problématiques

● Vers le déploiement continu○ Grands principes○ Solutions

● Le déploiement continu pas à pas○ IDE○ Versionnement & Gestion de configuration○ Build○ Intégration continue○ Tests & Qualité du code○ Bug tracking○ Outils de déploiement & de monitoring

Introduction

Changement vs Stabilité (1)

Changement vs Stabilité (2)

Time to market vs Opportunités

Industrialisation du changement

Mise en production naïveProblèmes courants rencontrésMise à jour des besoins

Le déploiement logiciel

Une mise en production standard

Développement

Compilation

Déploiement

Intégration

Validation / Recette manuelle

Mise en production

Problèmes fréquemment rencontrés

Développement

Mésinterprétation du cahier des chargesManque de configurationRessources locales incompatibles avec la productionBugs

Compilation

Quelles sources ?Quelles options de compilation ?Quelles dépendances de librairie ?Quelles versions ?Sur quelle plate-forme ?Qui est responsable ?

Déploiement

Arrêt du service ?Copie du binaire au bon endroit (bon tomcat)Viabilité du fichierTraçabilité du fichier mis à dispositionCommunication quand à la disponibilité du livrable

Deploiement - Anti-pattern

Un déploiement ? Quel déploiement ?

Intégration

Le livrable n’est pas suffisamment configurableLa configuration est mal faite

● Ressources inexistantes● Ressources incomplètes● Ressources pas à jour● Mauvaise plate-forme cible● Incompatibilités de version● Mise à jour des données manquante/incomplète

Elle nécessite une expertise techniqueElle est fastidieuse en cas de plate-forme fortement redondante

Anti-pattern d’intégration

Documentation fastidieuseAller-retours Dev-IntegrationModification de dernière minuteÉléments de cluster hétérogènesRelease de plus de quelques minutes

Recette

Test volatiles● non fiables● non reproductibles● incomplets

Tâches rébarbatives, manuelles, hautement sujettes à l’erreurEffet boite noire

Anti-pattern de recette

Tests manuels

Mise en production

Temps d’indisponibilitéComportement de l’application en condition réelleMulti-utilisateur

● Confidentialité des données● Concurrence

Tenue en chargeRetour en arrière

Mise en production - Anti-pattern

Temps d’indisponibilité excessifIssue imprévisible

Besoins mis à jour

Émergence de nouveaux besoins

Une mise en production rapide, sans risque

Visibilité des livrables : quoi, quand, oùVisibilité de la disponibilité/performance

Une mise en production doit devenir un processus automatisé, rapide, répétable et répété fréquemment, maîtrisé, prévisible, facilement inversable

Identification du livrable● Versionnement systématique

Build automatique

Validation / Non régression systématique● Tests unitaires automatisés● Tests d’intégration automatisés● Tests fonctionnels automatisés● Tests d’exploration

Communication● Centralisation des demandes d’amélioration /

correction● Statut des releases disponibles, des déploiements

effectués● Documentation type wiki

Qualité

Tests d’acceptanceTests de chargeMétriques

Automatisation du déploiement...

Vers le déploiement continu

Principes du déploiement continu

Grands principes

Processus fiable et répétable● Automatisation systématique● Versionnement systématique

3 grandes étapes : provisionner, installer, configurer

Grands principes

Affronter les tâches pénibles

Grands principes

“Bring Quality In”

Grands principes

Fait = Démontré à l’utilisateur

Grands principes

Responsabiliser toute l’équipe

Grands principes

Amélioration Continue

Le déploiement continu pas à pas

Solutions

Vers l’industrialisation logicielle● Outillage● Culture

Le déploiement continu pas à pas

Environnement de Développement IntégréVersionnementGestion de configurationBuild toolsIntégration continueTests de non régressionBug TrackingOutils de déploiementOutils de monitoring

IDEEnvironnement de

Développement Intégré

IDE - généralités

Les caractéristiques d’un logiciel robuste :● Code lisible● Couverture de tests automatique raisonnable● Architecture saine● Outils de debugging performants● Culture d’ingénierie qui valorise le refactoring

IDE - code lisible

Formateur de codeApplication de convention de codageDétection de redondance de code

IDE - tests

Création simplifiée de testsLancement et résultat des testsOutil de visualisation de couverture de tests

IDE - debugging

Debug en localDebug à distanceModification à chaud du code

IDE - refactoring

Identification systématique des références(code et commentaire)

Plugin de détection de code à factoriser/améliorer(PMD, Checkstyle)

IDE - interaction

SCM (Source Code Management)Gestion des dépendancesOutil de bug-trackingServeur web, avec accès en mode debugBase de données

IDE - offre

Intellij IDEAEclipseNetbeans

IDE - Netbeans 1/2

SimpleRobusteLié à OracleFonctionne mieux avec Maven* et GlassFish

IDE - Netbeans 2/2

+ Support des bases de données+ Support web (HTML, CSS, Javascript, PHP)+ Support de technologies avancées (JavaFX, Java 3D…)- Plugins moins nombreux- En retard sur les nouveaux langages- Utilisation de Maven quasi-obligatoire

IDE - Eclipse 1/2

Le plus répanduCommunauté / contributeurs importantsNombreux pluginsCouvre toutes les technologiesMulti-lingue

IDE - Eclipse 2/2

+ Versatile+ Nombre impressionnant d’extensions disponibles+ Compilation incrémentale+ Visualisation instantanée des erreurs+ Gestion des projets+ Hautement configurable- Configuration spécifique- Lourdeur- Instabilité

IDE - Intellij IDEA 1/2

StabilitéRichesse du support “out-of-the-box”Nombreux pluginsSupport natif d’UMLIntelligence contextuelle

IDE - Intellij IDEA 2/2

+ Recherche et Navigation+ Aide contextuelle pertinente+ Support de Maven+ Support d’Android+ Import de projets avancé+ Support enrichi des tests unitaires et de la couverture+ Debugging avancé de technologies phares- N’affiche pas les erreurs des fichiers clos- Ergonomie spécifique- Payant en version commerciale

TP Eclipse/IDEA/Netbeans

SCMGestion de Code Source

Stockage commun des ressources● code● configuration applicative● librairies● configuration serveur● scripts● schéma de la base de données● … tout ce qui est utile à un déploiement

SCM - Services

CentraliseVersionneRésout les conflits

Permet le catalogage (tagging)

SCM - Fonctionnalités

Commit/CheckoutBranching/MergingDiff current/tag/branch

Intégrité des données

SCM - Usage

Branching / merging ; deux approches :● branche systématique● tout sur le trunk

SCM - Usage

SCM - Solutions

CVSSVNGit

VersionnerGérer les dépendancesGérer la configuration systèmeGérer les environnements

Gestion de configuration

Gestion de conf - Versionner

Aussi important que les sources

VersionnerVersionner toutÊtre à jour

Messages explicites

Gestion de conf - Dépendances

Dépendances externesComposants logiciels

Gestion de conf - Flexibilité

Configuration et flexibilité● Coût de développement● Coût opérationnel● Risques induits

Gestion de conf - Typologie

Type de configuration● build● packaging● deployment● startup/runtime

Gestion de Configuration Applicative

Configuration Applicative● Ajout d’un nouvel environnement● Nouvelle version de l’application● Upgrade de release● Relocalisation d’un serveur● Le cas des VMsValidation de configuration● Isolation● Tests

Gestion de conf - Principes

Principes● Timing d’introduction des features● Stockage des Variables et valeurs de configuration● Automatisation de la configuration d’un environnement● Catalogue des valeurs de configuration● Nommage explicite● Modularité et encapsulation● DRY principle● Minimalisme● KISS principle● Tester la configuration

Gestion de conf - Environnement

Configuration environnement < Configuration application

Outils de gestion de configurationGestion du changement

Gestion de conf - Données

Données et application diffèrent en 2 points● volume● cycle de vie

Préserver les données entre 2 release● Database scripting● Modification incrémentaleContrainte supplémentaire● Rolling back Database et Zero downtime Release

Database scripting :● Initialisation DB : script, versionnement● Chaque Migration : script, versionnementButs :● Construire n’importe quelle version de la base● formaliser la dépendance de version {base:application}● Intégration au process de déploiement continu

Script d’initialisation● Création de la structure● Création des instances● Création des schémas● Alimenter les données de référencePour la release de projet simple, le process suivant peut suffir :● Suppression de la base N-1● Création de la base N● Alimentation en donnéeProjet plus complexe : Changement incrémentale

Migration IncrémentaleQu’est-ce :Roll-forward et Roll-backComment :Versionner la baseSQLUtilisation d’outil Flyway, Liquibase…Attention aux migrations dont le rollback est impossible

Migration IncrémentaleLe cas des Migrations destructrices● Copier le contenu de tables sous un autre nom versionné● Backup/Restore

Gestion de conf - données

Rolling back and zero downtime release● Cacher les transactions et permettre leur rejeu● Déploiement Blue-Green (prod-backup)

○ Backup Blue et restore sur Green○ Migrate Blue○ Rollback nécessaire : switch sur Green

● Découpler déploiement applicatif et migration de base○ Faire en sorte que chaque version applicative fonctionne avec la

version N et N+1 de la base de données

Build Tools

Un build doit être :Indépendant de la plate-formeReproductibleAutomatisableConfigurable

Gérer les dépendancesSe connecter au SCM

Build Tools - L’offre

Apache AntApache MavenGradle

Build Tools - Ant

“Modern build Tool”... qui date de 2000Implémentation Java unifiant des commandes hétérogènes dans des environnements diversUne sorte de “make”, sans la complexité d’usage

Flexible, adaptable, extensibleAbsence de contrainteInteraction avec un gestionnaire de dépendances

Ant - Cibles et points d’extension

Create Directory Layout

Ready to compile

Generate source

Compile

depends

extension-of

depends

Build Tools - Maven

Description du build du projet (POM)Description des dépendances du projetConventions par l’exceptionCycle de vie prédéfiniGestion de dépendances mutualisée (dépôt local/public)Nombreux plugins (appelés mojos pour Maven), que l’on peut développer soi-même

Maven lifecycle

Validate

Compile

Package

Install

Verify

Integration-test

Maven Profiles

Séparer les tests

Surcharger la configuration par environnement

Maven profiles - séparation des tests

Product

Integration Tests

Functionnal Tests

Parent Project

…<modules> <product></modules><profiles> <profile id=”full-test”> <modules> <module>integration-tests</module> <module>functional-tests</module> </modules> </profile></profiles><profiles> <profile id=”integration-test”> <modules> <module>integration-tests</module> </modules> </profile></profiles>...

Maven profiles

TP - Surcharge de configuration

Build Tools - Gradle

Le meilleur de Ant et MavenDSL (Domain-Specific Langage)DAG (Directed Acyclic Graph)Conçu pour les projets très vastesBuild incrémentalGoogle Android OS

Gradle lifecycle

Build Tools

TP - Intégration de Maven dans Jenkins

Intégration Continue

Commit Stage

Pipeline de déploiement

Code analysisBuild

Configuration Managment

SCM Intégration Continue

Automatic QA Test

Exploratory QA Test

Capacity / Load Test

UAT / Demo Production

Unit Test Test coverage

Artifact

Intégration Continue - Tests

Tests unitairesTests d’intégrationTests fonctionnelsTests d’exploration

Test unitaire

Tester des algorithmes isolésValider les règles de gestion unitairesPrévenir les risques de régressionCode testable = Code mieux pensé

Test unitaire - Solutions

JUnit + Mockito ou EasyMockSpock + Groovy

Intégration Continue

TP - Tests sous Jenkins

Test d’intégration

Vérifier le chargement du contexte du cadre applicatif (Spring, Java EE, etc.)Repenser son cloisonnement par technologieMettre à l’épreuve les transactions

Test d’intégration - Solutions

Spring TestContext FrameworkArquillian

Spring TestContext Framework@RunWith(SpringJUnit4ClassRunner.class)// specifies the Spring configuration to load for this test fixture@ContextConfiguration("daos.xml")public final class HibernateTitleDaoTests {

// this instance will be dependency injected by name

@Resource private HibernateTitleDao titleDao; public void testLoadTitle() throws Exception { Title title = this.titleDao.loadTitle(new Long(10)); assertNotNull(title); }}

Test 1

Test 2

Test Suite 1

Test 1

Test 2

Test Suite 2

chargement du contexte

suppression du contexte

chargement du contexte

suppression du contexte

Spring TestContext Framework - astuces● Charger des contextes allégés● @DirtiesContext● @IfProfileValue

Arquillian● Conteneur sur mesure● ShrinkWrap : artifact sur mesure

Test fonctionnel

Jouer des scénarios completsTester l’IHM au travers de laquelle on atteint toutes les couches applicativesValider les règles de gestion non unitairesNon régression

Test fonctionnel - Solution

Selenium 2 (webdriver, HQ et IDE)

Tests fonctionnels

TP - Selenium 2

TestsAller plus loin

Tests - Non régression

Pierre angulaire de la confiance qualitéCouvre toute l’applicationSystématisationMaintenance

Tests - Load Test

Teste l’application déployéeSimule la charge attendue par l’applicationLes statistiques de performance comme outils de non-régression

Tests - Stress Test

Teste l’application déployéeAugmente la charge pour identifier les limites

Tests - Couverture de code

Indice quant à la quantité de code testé100% n’est pas un objectifFavoriser le code sensible

Couverture de code - Solution

Emma -> JacocoCoberturaClover Cobertura

Qualité

Qualité du code

Homogénéiser le code

Les sept péchés capitaux du développement :● Duplication● Convention d’écriture● Manque de couverture● Bugs potentiels courants● Complexité● Documentation● Conception

Qualité du code - Concepts

Analyse statique du codeAnalyse DynamiqueProfilersMemory ToolsMonitoring Tools

Qualité du code - Précautions

Faux PositifsAdaptation au projetRègles personnellesLegacy projects

Qualité du code - Solutions

FindBugsPMDCheckStyle et JalopyCoveritySonarQube

Qualité du code - Recommandations

Les premières analyses ne seront pas pertinentesL’analyse statique seule est insuffisanteAutomatiser l’analyse de code (et l'exécuter souvent)Communiquer sur la qualitéÉviter l’excès de zèleAdapter l’analyse à chaque projetNe pas oublier les priorités

Qualité du code

TP Sonar

Bug Tracking

Disposer de métriques sur les problèmes découvertsCommuniquer sur la documentation projet

Bug Tracking - besoins

Classer les ticketsGérer les utilisateurs et leurs droitsDistinguer les projets/releasesÊtre connecté au SCMFaciliter la communicationConstituer un tableau de bord

Bug Tracking - cycle de vie

ASSIGNED

VERIFIEDREOPEN

CLOSED

RESOLVED

FIXEDDUPLICATEWONT FIXWORK FOR MEINVALIDREMINDLATER

Bug Tracking - Livraison

Bug Tracking - Solutions

BugZillaJiraMantisRedmineTrac (+ Agilo)

Déploiement

Déploiement - Scripting

One script to rule them allUn script principal pour tous les environnements

Déploiement - Le choix des armes

Utiliser la bonne technologie de déploiementUtiliser des outils de packaging éprouvés

Déploiement - objectif et méthode

Mise à niveau ou Installation complèteDéploiement = processus idempotentÉvolution incrémentale

Déploiement à grande echelle

Déploiement à grande échelle

Déploiement - astuces

Automatisation● Chemins relatifs● Éliminer les étapes manuelles

Versionning● Marquer les binaires avec la version SCM● Ne pas commiter les binaires : Nexus, Archiva

Tests● Test failed != Build Failed● Smoke tests

Deploiement - Puppet

Logiciel d’automatisation qui définit et vérifie l’état d’une infrastructure tout au long du cycle de développement● Définir l’état attendu d’un serveur● Classes, module● Piocher dans l’existant

Déploiement - Puppet

● Fonctionne en Client/Serveur● Chaque serveur de l’infrastructure est un client (puppet

agent)● Le serveur puppet (puppet master) héberge les modules● Les modules sont rendu paramétrable pour s’ajuster

sur chaque client● Chaque client possède les modules qui le concerne ● A chaque run puppet, un différentiel est établi entre la

configuration définie sur le master et ce que rapporte les agents.

Déploiement - Puppet

TP Puppet : Configurer Apache

Monitoring

Superviser quoi ?

Les temps d’exécution...● de service● de service distantL’occupation mémoireLes ressources partagées● pool de threads● pool de connexions● DLQ et queue sevrée/surchargéeLes succès/échecs

Monitoring Java

Logs internes● choisir le niveau et le support (fichiers séparés, voire en

base de données)Standard JMX● exposition de propriétés du SI● de nombreuses API phares le mettent en oeuvre nativementSurveillance de la JVM● analyse des performances et de l’occupation mémoire

Exploiter le monitoring

● Rendu graphique des métriques, dashboard(ex: Graphite)

● Seuils d’alerte sur des métriques réseau, souvent à l’aide d’agents(ex: Zabbix)

● Analyse temps réel de la JVM et suivi fin en cas de dépassement des moyennes constatées(ex: AppDynamics)

● Exploitation de logs(ex: splunk, cacti, loggly, logstash, kibana, nagios…)

Monitoring

Sur mesureDiagnostic temps réelAlerte

Monitoring

TP Instrumentation et exploitation

blog.ippon.frippon.fr atomes.com

@ippontech contact@ippon.fr

Formation Usine Logicielle gratuite par Ippon 2014

Technology

Usine Engelhardt

Ippon Back Comfo Pro · Ippon Back Comfo Pro. Title. Ippon_Back_Comfo_Pro. Created Date. 7/17/2013 6:05:54 PM

INGENIERIE LOGICIELLE

Usine logicielle ios

Mise en place d’une usine logicielle pour technologies Microsoft et non Microsoft avec TFS 2012

Formation html5 CSS3 offerte par ippon 2014

Plateforme logicielle acciline+

Usine logicielle à Orange Labs

Revista Ippon 01

Scub Foundation, usine logicielle Java libre

La mesure logicielle

01 - Jornal Ippon 08

Formation Total Tests Chez IPPON Enterprise Java Delivery

Xebicon'16 : Kodo Kojo, une usine logicielle en trois clics. Par Antoine Le Taxin et Jean-Pascal Thiery, Développeur Full Stack pour Kodo Kojo

Usine volkswagen

Architecture Logicielle Exercice noté

Qualité logicielle - Introduction

Usine école

Ippon! K.O.! Finish! — Kamppailulajit mangassa

Usine Logicielle 2013