Integration continueIntegration continue
et autres distractionset autres distractions
Olivier ETIENNE - OrangeOlivier ETIENNE - Orange
2
Plan
● Théorie
– Le cycle de développement
– Les contraintes actuelles
– Les pratiques associées
– …
● Jenkins au coeur de l'automatisation
● Exemple de mise en oeuvre
3
Contexte du développement logiciel
● Cycle en V
● Cycles courts / Iteration
4
Le cycle en V favorise l'effet tunnelLe cycle en V favorise l'effet tunnelLe cycle en V favorise l'effet tunnelLe cycle en V favorise l'effet tunnel
5
Contexte du développement logiciel
● Cycles courts / Iteration
6
Contexte du développement logiciel
Cycles courts
Cycles V
7
Contraintes du marché
Deployer vite et souvent
– Etsy : 25 / jour
– Github : 25 /jour
– Facebook : 2 / jour
– Flickr : 10 / jour
– Google : 2-3 / semaine
8
Et nous ?
● TTM
● Concurrence forte
● Etre les premiers à innover
● Besoin d'étaler la validation
Nous avons
presque les même
attentes que les
géants du WEB !
9
OK et donc...
... comment livrer plus vite jours en prod ???
● Quelques pistes :
– Changement d'état d'esprit : Cargo → Hors-bord
– DEVOPS
– Automatisation de la forge logicielle
– Automatisation des tests
10
Changement d'état d'esprit
Le hors-bord
✔ Rapide
✔ Faible capacité
✔ Courte distance couverte
✔ Manoeuvrable
Le hors-bord soft
✔ Vite sur le marché
✔ Faible quantité / impact
✔ Rollback rapide
✔ Changements vite effectués
Le hors-bord soft
✔ Vite sur le marché
✔ Faible quantité / impact
✔ Rollback rapide
✔ Changements vite effectués
11
DEVOPS
plan code build test
release deploy operate monitor
12
Devs vs Ops
13
Deployer plus vite
✖✖✔✔
à quel prix ?
14
Le cycle de développement
CodeCode
CompileCompile
Unit TestsUnit Tests
Integ. TestsInteg. Tests
Load TestsLoad Tests
ReleaseRelease
DeployDeploy
CommitCommit
TESTTEST
DEVDEV
DEPLOYDEPLOY
15
What if...
CodeCode
CompileCompile
Unit TestsUnit Tests
Integ. TestsInteg. Tests
Load TestsLoad Tests
ReleaseRelease
DeployDeploy
CommitCommit
Equipe
> 10
Multi site
Eco
système
complèxe
> 100
commit/j
16
What if...
CodeCode
CompileCompile
Unit TestsUnit Tests
Integ. TestsInteg. Tests
Load TestsLoad Tests
ReleaseRelease
DeployDeploy
CommitCommit
0,5j
10'
1h
>12h
17
Mais aussi, pour être sûr
CodeCode
CompileCompile
Unit TestsUnit Tests
Integ. TestsInteg. Tests
Load TestsLoad Tests
ReleaseRelease
DeployDeploy
CommitCommit
Règle de
codage
Audit de
qualité
Couverture
de code
Consommation
de ressources
J'ai scriptéJ'ai scripté
19
Jenkins
20
Qu'est-ce qu'une SW Factory ?
● Chaine d'assemblage d'une usine
● Besoin d'éléments préparés
(On ne trouve pas de minerais brut en entrée
d'une usine automobile)
● Donne la cadence et synchronise
Ordonanceur
de taches
21
Pré requis : Scripter et automatiser
✔ Le build : maven, ant, grunt, …
✔ Les tests : Junit, *Unit, …
✔ L'environnement : mock, stubs, …
✔ La gestion de conf : git, svn, … et leur workflow
✔ Règles de codage
✔ Métriques d'analyse de code
22
Les concepts
✔ Les executors
✔ Les jobs
✔ Les workspace
✔ Les historiques
✔ Les vues
23
Jenkins : Les jobs
● Déclencheurs
– Horaire
– Surveillance repo
● Pre build
– Préparation de l'environnement
● “ Build ”
– Compilation
– Exécution de scripts
– Déployement dans l'environnement de test
– Exécution des tests
● Post build
– Génération de rapports
– Notification par mail
– Déploiement / mise à dispo sur l'environnement cible
24
Jenkins : Les jobs
SCM
Déclencheur
Tache principale
Post traitements
25
Jenkins : Les jobs
Evolution dans
le temps
Historique
Environnement
Séquence
26
Autres motivations
✔ Si on builde sous jenkins, on builde n'importe où
✔ Jenkins travaille H24 …pas nous
✔ Jenkins est connecté au repos de code …pas
nous
✔ Jenkins peut faire 100 fois la même tâche dans
la journée, sans broncher …pas nous
✔ Jenkins n'est pas interrompu par les collèguesJenkins n'est pas interrompu par les collègues
27
Quelques plugins
● Sonar : Qualité de code
● Maven : Build / Deploy / Release
● Tests : Lanceur de test, génération de rapports
● Throttle : Synchronisation / gestion des ressources
● BuildPipeLine : Représentation de graphes d'exécution
● Ush over ssh : exécution/déploiement over ssh
● Green balls : Le plus important !!!
28
Sonar
29
Sonar
30
cas concret :
La TV d'Orange
La genèse (août 2013)
• 25% du sprint AR à tester
• Tests longs et rébarbatifs
• 1 code / x STB => Non reg couteuse
• Frilosité sur les gros chantiers / changements de
code
• Echec des solutions dédiées
• Multitude de solutions généralistes
• Echec des solutions dédiées
• Multitude de solutions généralistes
Test
Status
Bref les tests c'était ça...
TEST1 sprint =
Qualité variable
en fonction du
testeur
Pénible
Beaucoup de
tests
DEV DEV DEV
• Impossible de tout tester
• Confiance médiocre
• Non regression coûteuse
• Réticence à faire des refactorings
Comment vous testiez ?
34
Mise en oeuvre de nos Jenkins
● Jenkins de build
– Compilation
– TU
– Analyse de la qualité de code
– Déploiement des SNAPSHOT/RELEASES
● JenkinsS de test
35
Mise en oeuvre de nos Jenkins
● Jenkins de build
● Jenkins S de test
– Compilation / déploiement des outils de test
– Compilation des Simulateurs/Stubs
– Récupération des builds depuis le jenkins build-TU
– Déploiement de l’environnement de test
– Déploiement du SOFT sur les boitiers STB
– Pilotage électrique des boitiers TV (reboot)
– Lancement des test suites : Reboot / Vérification de
l’environnement / Jeu d’une séquence / Vérifications
– Mise à jour des rapports
– Mise à jour de la campagne de test sous QC
Tests automatiques AR : Février 2015
Chaine complètement automatisée
buildbuild TUTU
Tests
Fonctionnels
Tests
Fonctionnels
RapportRapport
Tests
d’endurance
Tests
d’endurance
DeployDeploy
every night
Big picture
On demand
Code
Repo
update
TestSuitesdeploy
update
reset
selenium
Delivery
Status
Test
Repo
Questions ?

Integration continue - Introduction

  • 1.
    Integration continueIntegration continue etautres distractionset autres distractions Olivier ETIENNE - OrangeOlivier ETIENNE - Orange
  • 2.
    2 Plan ● Théorie – Lecycle de développement – Les contraintes actuelles – Les pratiques associées – … ● Jenkins au coeur de l'automatisation ● Exemple de mise en oeuvre
  • 3.
    3 Contexte du développementlogiciel ● Cycle en V ● Cycles courts / Iteration
  • 4.
    4 Le cycle enV favorise l'effet tunnelLe cycle en V favorise l'effet tunnelLe cycle en V favorise l'effet tunnelLe cycle en V favorise l'effet tunnel
  • 5.
    5 Contexte du développementlogiciel ● Cycles courts / Iteration
  • 6.
    6 Contexte du développementlogiciel Cycles courts Cycles V
  • 7.
    7 Contraintes du marché Deployervite et souvent – Etsy : 25 / jour – Github : 25 /jour – Facebook : 2 / jour – Flickr : 10 / jour – Google : 2-3 / semaine
  • 8.
    8 Et nous ? ●TTM ● Concurrence forte ● Etre les premiers à innover ● Besoin d'étaler la validation Nous avons presque les même attentes que les géants du WEB !
  • 9.
    9 OK et donc... ...comment livrer plus vite jours en prod ??? ● Quelques pistes : – Changement d'état d'esprit : Cargo → Hors-bord – DEVOPS – Automatisation de la forge logicielle – Automatisation des tests
  • 10.
    10 Changement d'état d'esprit Lehors-bord ✔ Rapide ✔ Faible capacité ✔ Courte distance couverte ✔ Manoeuvrable Le hors-bord soft ✔ Vite sur le marché ✔ Faible quantité / impact ✔ Rollback rapide ✔ Changements vite effectués Le hors-bord soft ✔ Vite sur le marché ✔ Faible quantité / impact ✔ Rollback rapide ✔ Changements vite effectués
  • 11.
    11 DEVOPS plan code buildtest release deploy operate monitor
  • 12.
  • 13.
  • 14.
    14 Le cycle dedéveloppement CodeCode CompileCompile Unit TestsUnit Tests Integ. TestsInteg. Tests Load TestsLoad Tests ReleaseRelease DeployDeploy CommitCommit TESTTEST DEVDEV DEPLOYDEPLOY
  • 15.
    15 What if... CodeCode CompileCompile Unit TestsUnitTests Integ. TestsInteg. Tests Load TestsLoad Tests ReleaseRelease DeployDeploy CommitCommit Equipe > 10 Multi site Eco système complèxe > 100 commit/j
  • 16.
    16 What if... CodeCode CompileCompile Unit TestsUnitTests Integ. TestsInteg. Tests Load TestsLoad Tests ReleaseRelease DeployDeploy CommitCommit 0,5j 10' 1h >12h
  • 17.
    17 Mais aussi, pourêtre sûr CodeCode CompileCompile Unit TestsUnit Tests Integ. TestsInteg. Tests Load TestsLoad Tests ReleaseRelease DeployDeploy CommitCommit Règle de codage Audit de qualité Couverture de code Consommation de ressources
  • 18.
  • 19.
  • 20.
    20 Qu'est-ce qu'une SWFactory ? ● Chaine d'assemblage d'une usine ● Besoin d'éléments préparés (On ne trouve pas de minerais brut en entrée d'une usine automobile) ● Donne la cadence et synchronise Ordonanceur de taches
  • 21.
    21 Pré requis :Scripter et automatiser ✔ Le build : maven, ant, grunt, … ✔ Les tests : Junit, *Unit, … ✔ L'environnement : mock, stubs, … ✔ La gestion de conf : git, svn, … et leur workflow ✔ Règles de codage ✔ Métriques d'analyse de code
  • 22.
    22 Les concepts ✔ Lesexecutors ✔ Les jobs ✔ Les workspace ✔ Les historiques ✔ Les vues
  • 23.
    23 Jenkins : Lesjobs ● Déclencheurs – Horaire – Surveillance repo ● Pre build – Préparation de l'environnement ● “ Build ” – Compilation – Exécution de scripts – Déployement dans l'environnement de test – Exécution des tests ● Post build – Génération de rapports – Notification par mail – Déploiement / mise à dispo sur l'environnement cible
  • 24.
    24 Jenkins : Lesjobs SCM Déclencheur Tache principale Post traitements
  • 25.
    25 Jenkins : Lesjobs Evolution dans le temps Historique Environnement Séquence
  • 26.
    26 Autres motivations ✔ Sion builde sous jenkins, on builde n'importe où ✔ Jenkins travaille H24 …pas nous ✔ Jenkins est connecté au repos de code …pas nous ✔ Jenkins peut faire 100 fois la même tâche dans la journée, sans broncher …pas nous ✔ Jenkins n'est pas interrompu par les collèguesJenkins n'est pas interrompu par les collègues
  • 27.
    27 Quelques plugins ● Sonar: Qualité de code ● Maven : Build / Deploy / Release ● Tests : Lanceur de test, génération de rapports ● Throttle : Synchronisation / gestion des ressources ● BuildPipeLine : Représentation de graphes d'exécution ● Ush over ssh : exécution/déploiement over ssh ● Green balls : Le plus important !!!
  • 28.
  • 29.
  • 30.
  • 31.
    La genèse (août2013) • 25% du sprint AR à tester • Tests longs et rébarbatifs • 1 code / x STB => Non reg couteuse • Frilosité sur les gros chantiers / changements de code • Echec des solutions dédiées • Multitude de solutions généralistes • Echec des solutions dédiées • Multitude de solutions généralistes
  • 32.
  • 33.
    TEST1 sprint = Qualitévariable en fonction du testeur Pénible Beaucoup de tests DEV DEV DEV • Impossible de tout tester • Confiance médiocre • Non regression coûteuse • Réticence à faire des refactorings Comment vous testiez ?
  • 34.
    34 Mise en oeuvrede nos Jenkins ● Jenkins de build – Compilation – TU – Analyse de la qualité de code – Déploiement des SNAPSHOT/RELEASES ● JenkinsS de test
  • 35.
    35 Mise en oeuvrede nos Jenkins ● Jenkins de build ● Jenkins S de test – Compilation / déploiement des outils de test – Compilation des Simulateurs/Stubs – Récupération des builds depuis le jenkins build-TU – Déploiement de l’environnement de test – Déploiement du SOFT sur les boitiers STB – Pilotage électrique des boitiers TV (reboot) – Lancement des test suites : Reboot / Vérification de l’environnement / Jeu d’une séquence / Vérifications – Mise à jour des rapports – Mise à jour de la campagne de test sous QC
  • 36.
    Tests automatiques AR: Février 2015 Chaine complètement automatisée buildbuild TUTU Tests Fonctionnels Tests Fonctionnels RapportRapport Tests d’endurance Tests d’endurance DeployDeploy
  • 37.
    every night Big picture Ondemand Code Repo update TestSuitesdeploy update reset selenium Delivery Status Test Repo
  • 38.

Notes de l'éditeur

  • #4 Avantages et inconvénients du cycle en V Durée Effet Tunnel Cout des détection tardives de defects
  • #5 Effet Tunnel = Trop de temps avant de voir un feature
  • #6 Changements des méthodes agiles et iteratives Cycles courts Livraisons régulières Beaucoup de communication / interactions avec le client
  • #7 On traverse le pacifique Ou bien on relie deux îles
  • #8 Déployer toujours plus vite pour garder ses clients Etre le premier à amener l'innovation
  • #10 jkhqsjkdhqs
  • #33 One year ago, to test a TV App, we used to do like any TV user. Okay, we didn’t have beer or cheetos… Not every day at least… So, we take the product specification and test plans, and for each new functionality we have to run the tests and note the result in a report. We also have to do that on for functionality that we MAY have been impacted (non regression tests) We do that in order to give a status for each release in order to pass to the next phase of our process => QA team with END2END TESTS
  • #34 In our development teams, these tests are passed during one full week for each sprint. The rythme was 3 week of coding+Unit Testing / One week of functional tests Because of our context and fragmentation, we were unable to run all tests on all configuration within a week So, every change was very expensive to test and all refactoring activities were really risky. NO REFACTORING WAS A BIG PROBLEM ON LEGACY CODE And also, these activities of manual testing were really boring ! A lot of developer’s time spent in test https://www.flickr.com/photos/robnwatkins/
  • #38 Now, the big picture of what we have now is : Moved from continuous compilation to continuous integration and test Update the test campaign status