2. 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
4. 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
7. 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. 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
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
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
20. 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. 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
✔ Les executors
✔ Les jobs
✔ Les workspace
✔ Les historiques
✔ Les vues
23. 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. 24
Jenkins : Les jobs
SCM
Déclencheur
Tache principale
Post traitements
25. 25
Jenkins : Les jobs
Evolution dans
le temps
Historique
Environnement
Séquence
26. 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. 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 !!!
31. 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
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 oeuvre de 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 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
Avantages et inconvénients du cycle en V
Durée
Effet Tunnel
Cout des détection tardives de defects
Effet Tunnel = Trop de temps avant de voir un feature
Changements des méthodes agiles et iteratives
Cycles courts
Livraisons régulières
Beaucoup de communication / interactions avec le client
On traverse le pacifique
Ou bien on relie deux îles
Déployer toujours plus vite pour garder ses clients
Etre le premier à amener l'innovation
jkhqsjkdhqs
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
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/
Now, the big picture of what we have now is :
Moved from continuous compilation to continuous integration and test
Update the test campaign status