Formation Usine Logicielle gratuite par Ippon 2014

Usine logicielle Java
L’industrialisation de la
mise en production

Ippon Technologies © 2014
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)
VS

Changement vs Stabilité (2)
VS

Time to market vs Opportunités
VS

Industrialisation du changement
VS

Mise en production naïve
Problèmes courants rencontrés
Mise à 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 charges
Manque de configuration
Ressources locales incompatibles avec la production
Bugs

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 fichier
Traçabilité du fichier mis à disposition
Communication quand à la disponibilité du livrable

Deploiement - Anti-pattern
Un déploiement ? Quel déploiement ?

Intégration
Le livrable n’est pas suffisamment configurable
La 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 technique
Elle est fastidieuse en cas de plate-forme fortement
redondante

Anti-pattern d’intégration
Documentation fastidieuse
Aller-retours Dev-Integration
Modification de dernière minute
Éléments de cluster hétérogènes
Release de plus de quelques minutes

Recette
Test volatiles
● non fiables
● non reproductibles
● incomplets
Tâches rébarbatives, manuelles, hautement sujettes à l’
erreur
Effet boite noire

Anti-pattern de recette
Tests manuels

Mise en production
Temps d’indisponibilité
Comportement de l’application en condition réelle
Multi-utilisateur
● Confidentialité des données
● Concurrence
Tenue en charge
Retour en arrière

Mise en production - Anti-pattern
Temps d’indisponibilité excessif
Issue 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’acceptance
Tests de charge
Mé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é
Versionnement
Gestion de configuration
Build tools
Intégration continue
Tests de non régression
Bug Tracking
Outils de déploiement
Outils de monitoring

IDE
Environnement 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 code
Application de convention de codage
Détection de redondance de code

IDE - tests
Création simplifiée de tests
Lancement et résultat des tests
Outil de visualisation de couverture de tests

IDE - debugging
Debug en local
Debug à distance
Modification à 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épendances
Outil de bug-tracking
Serveur web, avec accès en mode debug
Base de données

IDE - offre
Intellij IDEA
Eclipse
Netbeans

IDE - Netbeans 1/2
Simple
Robuste
Lié à Oracle
Fonctionne 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épandu
Communauté / contributeurs importants
Nombreux plugins
Couvre toutes les technologies
Multi-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 plugins
Support natif d’UML
Intelligence 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

IDE
TP Eclipse/IDEA/Netbeans

SCM
Gestion de Code Source

SCM
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
Centralise
Versionne
Résout les conflits
Permet le catalogage (tagging)

SCM - Fonctionnalités
Commit/Checkout
Branching/Merging
Diff 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
CVS
SVN
Git

Versionner
Gérer les dépendances
Gérer la configuration système
Gérer les environnements
Gestion de configuration

Gestion de conf - Versionner
Aussi important que les sources
Versionner
Versionner tout
Être à jour
Messages explicites

Gestion de conf - Dépendances
Dépendances externes
Composants 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 VMs
Validation 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 configuration
Gestion 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émentale
Contrainte supplémentaire
● Rolling back Database et Zero downtime Release

Database scripting :
● Initialisation DB : script, versionnement
● Chaque Migration : script, versionnement
Buts :
● 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érence
Pour 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ée
Projet plus complexe : Changement incrémentale

Migration Incrémentale
Qu’est-ce :
Roll-forward et Roll-back
Comment :
Versionner la base
SQL
Utilisation d’outil Flyway, Liquibase…
Attention aux migrations dont le rollback est impossible

Migration Incrémentale
Le 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

Build Tools
Un build doit être :
Indépendant de la plate-forme
Reproductible
Automatisable
Configurable
Gérer les dépendances
Se connecter au SCM

Build Tools - L’offre
Apache Ant
Apache Maven
Gradle

Build Tools - Ant
“Modern build Tool”... qui date de 2000
Implémentation Java unifiant des commandes hétérogènes
dans des environnements divers
Une sorte de “make”, sans la complexité d’usage
Flexible, adaptable, extensible
Absence de contrainte
Interaction 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 projet
Conventions par l’exception
Cycle de vie prédéfini
Gestion 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
Test
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 Maven
DSL (Domain-Specific Langage)
DAG (Directed Acyclic Graph)
Conçu pour les projets très vastes
Build incrémental
Google Android OS

Gradle lifecycle
<inclure un cycle de vie du build gradle>

Build Tools
TP - Intégration de Maven dans Jenkins

Intégration Continue

Commit Stage
Pipeline de déploiement
Code
analysis
Build
Configuration
Managment
SCM
Intégration
Continue
Automatic
QA Test
Exploratory
QA Test
Capacity / Load Test
UAT / Demo Production
IDE
Unit Test
Test
coverage
Artifact

Intégration Continue - Tests
Tests unitaires
Tests d’intégration
Tests fonctionnels
Tests d’exploration

Test unitaire
Tester des algorithmes isolés
Valider les règles de gestion unitaires
Prévenir les risques de régression
Code testable = Code mieux pensé

Test unitaire - Solutions
JUnit + Mockito ou EasyMock
Spock + Groovy
DEMO

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 technologie
Mettre à l’épreuve les transactions

Test d’intégration - Solutions
Spring TestContext Framework
Arquillian
DEMO

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 complets
Tester l’IHM au travers de laquelle on atteint toutes les
couches applicatives
Valider les règles de gestion non unitaires
Non régression

Test fonctionnel - Solution
Selenium 2 (webdriver, HQ et IDE)
DEMO

Tests fonctionnels
TP - Selenium 2

Tests
Aller plus loin

Tests - Non régression
Pierre angulaire de la confiance qualité
Couvre toute l’application
Systématisation
Maintenance

Tests - Load Test
Teste l’application déployée
Simule la charge attendue par l’application
Les statistiques de performance comme outils de non-
régression

Tests - Stress Test
Teste l’application déployée
Augmente la charge pour identifier les limites

Tests - Couverture de code
Indice quant à la quantité de code testé
100% n’est pas un objectif
Favoriser le code sensible

Couverture de code - Solution
Emma -> Jacoco
Cobertura
Clover 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 code
Analyse Dynamique
Profilers
Memory Tools
Monitoring Tools

Qualité du code - Précautions
Faux Positifs
Adaptation au projet
Règles personnelles
Legacy projects

Qualité du code - Solutions
FindBugs
PMD
CheckStyle et Jalopy
Coverity
SonarQube

Qualité du code - Recommandations
Les premières analyses ne seront pas pertinentes
L’analyse statique seule est insuffisante
Automatiser l’analyse de code (et l'exécuter souvent)
Communiquer sur la qualité
Éviter l’excès de zèle
Adapter l’analyse à chaque projet
Ne pas oublier les priorités

Qualité du code
TP Sonar

Bug Tracking

Bug Tracking
Disposer de métriques sur les problèmes découverts
Communiquer sur la documentation projet

Bug Tracking - besoins
Classer les tickets
Gérer les utilisateurs et leurs droits
Distinguer les projets/releases
Être connecté au SCM
Faciliter la communication
Constituer un tableau de bord

Bug Tracking - cycle de vie
NEW
ASSIGNED
VERIFIEDREOPEN
CLOSED
RESOLVED
FIXED
DUPLICATE
WONT FIX
WORK FOR ME
INVALID
REMIND
LATER

Bug Tracking - Livraison

Bug Tracking - Solutions
BugZilla
Jira
Mantis
Redmine
Trac (+ Agilo)

Déploiement

Déploiement - Scripting
One script to rule them all
Un script principal pour tous les environnements

Déploiement - Le choix des armes
Utiliser la bonne technologie de déploiement
Utiliser des outils de packaging éprouvés

Déploiement - objectif et méthode
Mise à niveau ou Installation complète
Dé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 distant
L’occupation mémoire
Les ressources partagées
● pool de threads
● pool de connexions
● DLQ et queue sevrée/surchargée
Les 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 nativement
Surveillance 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 mesure
Diagnostic temps réel
Alerte

Monitoring
TP Instrumentation et exploitation

blog.ippon.frippon.fr atomes.com
@ippontech contact@ippon.fr

Formation Usine Logicielle gratuite par Ippon 2014

Contenu connexe

Tendances

Similaire à Formation Usine Logicielle gratuite par Ippon 2014

Plus de Ippon

Formation Usine Logicielle gratuite par Ippon 2014