Module 2 IUT Bobigny : Automatisation de la chaîne de production logicielle

AUTOMATISATION ET INDUSTRIALISATION
DE LA CHAÎNE DE PRODUCTION
Gestion de projet web – Module 2

MODULE 2 : INGÉNIERIE DE LA CHAÎNE DE
PRODUCTION

 Intégration continue, usine de développement

Gestion de projet Web | IUT Bobigny 2012-2013 | Frédéric RIVAIN - frederic.rivain@gmail.com
 Test et qualité logicielle, automatisation des tests

 Qualité du code

 Déploiements

 Petit rappel : dans un contexte d’entreprise…
Projetez-vous !

2

OBJECTIFS
 Optimiser

 Contrôler

 Fiabiliser

 Accélérer

 Pour cela:
 Automatiser
 If you have to do it more than once, AUTOMATE IT!
 Industrialiser
 Scripter
 Mesurer 3

DÉFINITION
 Continuous integration (CI) is a

set of continuous processes to
improve quality control: small
pieces of effort, applied frequently.

 Continuous integration aims to
improve the quality of software and
to reduce the time taken to deliver
it, by switching from the traditional
practice of applying quality
control after completing all
development to a continuous
control process.

 The value of continuous
integration:
 Reduce risks
 Reduce repetitive processes
 Enforce higher software quality
 Generate deployable software 5
 Establish greater project
confidence

MISE EN ŒUVRE D’UNE INTÉGRATION
CONTINUE
 Set up a continuous integration

server to produce nightly builds that:
 Compiles the project
 Generates code reference
documentation
 Deploys on preprod
 Runs automated test
 Issues a build report
 Automatically track bugs

 Tools
 Jenkins http://jenkins-ci.org/
 Atlassian Bamboo
https://www.atlassian.com/software/ba
mboo/overview
 Cruise Control 6
http://cruisecontrol.sourceforge.net/

7
UNE USINE DE DÉVELOPPEMENT

SHORT FEEDBACK LOOP
 In addition to continuous integration, set up a build that

executes with every commit, and does just 3 things:
checkout source code, compile, run unit tests, in a very
short time (a few minutes max)

8

ENVIRONNEMENTS
 Development: Development is done on the local environment of the developer
where he implements and runs unit tests.

 Integration: Developments are deployed on Integration for integration testing and
debug.

 Preproduction: Developments are then deployed on Preproduction for
performance and load test, security tests, and final acceptance. The Preproduction
environment is a copy of the Production environment.

 Production: This is the live environment.

 Staging: This is a copy of the Production environment, hidden, where data and
content updates can be tested before pushing them to Production.

9

TYPOLOGIES DE TESTS
 Tests unitaires

 Tests d’intégration
 Tests de non-
régression
 Tests fonctionnels
 Tests d’interface ou
IHM
 Tests de compatibilité
navigateur
 Tests de charge
 Tests de performance
 Tests de sécurité

11

UNIT TESTING
 It is the responsibility of

developers to properly unit
test their code.
 A unit test:
 Does not communicate with the
database
 Does not communicate with
external resources
 Does not manipulate one or
multiple files
 Can be run in parallel with other
unit tests
 You do not need to configure
the launch of a unit test
 Unit tests should be mocked to 12

avoid dependencies.

TDD: TEST DRIVEN
DEVELOPMENT
 La méthode TDD repose sur un des

principes Test First d'une methode
de développement agile
intitulée Extreme
Programing appelé aussi XP.
 TDD est une pratique de
régulation de la programmation, dont
l’objectif est de détecter les erreurs
le plus tôt possible.

 La démarche TDD consiste à
1. écrire un test et vérifier qu’il échoue
2. écrire le code le plus simple qui
fasse passer ce test
3. Refactorer 13
4. Puis retour au step 1.

FUNCTIONAL AND ACCEPTANCE TESTING
 QA team is in charge of Acceptance Testing to validate the new

features.
 Those Acceptance tests need to be designed and implemented
with every new feature, then updated if features evolve.

 Tools
 Fitness http://fitnesse.org/
 GreenPepper http://www.greenpeppersoftware.com

14

AUTOMATING TESTS
 You should automate tests and run them locally and from the

continuous integration server:
 Unit tests
 Code review and code analysis
 Performance testing
 Standard use-case scenario and GUI testing
 Load testing
 W3C standard testing
 Browser compatibility

 List tests to automate, specify, script and deploy into the
continuous integration server.
 Document and don’t forget to maintain tests

 Check automation tools
 Each language has its own set of tools (PHPunit, Junit…)
 Selenium http://seleniumhq.org/ 15
 Watir http://watir.com/

DEBUG
 Key principle:

 Debug before coding new stuff!

 Debug all bugs as much and early as
possible:
• Functional issues
• Technical bugs
• Code review improvements
• Performance and load optimizations

 Sometimes some bugs are not worth
fixing. Bugs must be reviewed by the
Product Owner. Unnecessary bugs must be
closed.

Be aware that bugs that are not fixed right
away will probably never be fixed.

 Do not accumulate a huge pile of bugs.
16

LOAD TESTING
 Validate that your system can support heavy

traffic load.
 Implement appropriate load-testing tools to
emulate a user-case scenario:
1. Before building your load test plan, write down
a user workflow and define load criteria for
each step.
2. Be careful of the difference between
“concurrent players” and “request per second”.
1000 VU / day = 20 concurrent requests (2%)
3. Check load metrics both on the client-side
(load-testing tool) but also on the server side.
4. Simulate it
5. If needed, set up distributed load-testing
6. Automate it

 Tools: 17
 Jmeter http://jakarta.apache.org/jmeter/

PERFORMANCE TESTING
 Performance is key to a good user-experience. It impacts conversion and SEO.

 Performance and optimization should be part of any development.
 Each new module or web page needs to be performance tested.
 Add performance tracking in the logs (could be used for automated testing): both
for applications and API to track performance evolution.

 Never exceed 1 sec of waiting time, to display a web page or load an application
module in normal conditions.
 Any loading time above 1 second should display a “loading” indicator or warning
message.

 Automate performance testing (into the continuous integration).
 Minimum grade should be A/A on Page Speed Grade/Y Slow performance scale.

 Tools
 Gtmetrix http://gtmetrix.com/
 Webpagetest http://www.webpagetest.org/
 Chrome extension for PageSpeed and Yslow 18

SECURITY AND FRAUD
 Security should be part of the product features. Make better security part of the

added value for customers.

 Introduce specific security logs in the monitoring (password resets, email
changes, login failures…). Graph it to identify spikes of variations and alerts.

 Include security tests in your Continuous integration to validate negative flows.
Also test your invariants: « this page should always require a login », « this pages
should always be SSL ». Establish the baseline and look for deviations from it.
Work on preventing false positives.

 Switch to 100% SSL. Test SSL : https://www.ssllabs.com
 No passwords in plain text.

 OWASP https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

 Phishing and safe browsing:
 http://code.google.com/apis/safebrowsing 19
 http://www.phishtank.com/

STANDARD VALIDATION AND ACCESSIBILITY
 Web pages should try and respect W3C standard to

avoid browser html interpretation errors and possible
performance decrease.

 Use http://validator.w3.org/unicorn
 Check for broken links: http://validator.w3.org/checklink
 Automate W3C standard testing.

 Still be careful that this should not be contradictory with
performance and should not consume too much time.
Even Google is not W3C compliant!

 Also try and respect basic accessibility rules.
 Check http://wave.webaim.org/ 20

BROWSER COMPATIBILITY
 Because of web browser fragmentation, it

is critical to check the display of
applications on multiple browsers.

 Concentrate on the most widely used:
 http://www.w3schools.com/browsers/browse
rs_stats.asp
 http://gs.statcounter.com/

 Not that easy to automate:
 Set up multiple VM with Selenium scripts

 Tools
 http://browsershots.org/
 https://browserlab.adobe.com
21
 http://www.browserscope.org

CODING BEST PRACTICES
 Use coding guidelines.

 These guidelines should be concise and easy to read.
 Follow naming conventions.

 Code simply and efficiently.
 Code should be fully in English and well commented.
 Code should be modular.
 Always think “performance” and “optimization”
 Someone will work on your code one day so make it easy to understand.
 Generate automatically a developer reference doc from your code.
 Refactor frequently

 See:
 Google styleguide http://code.google.com/p/google-styleguide/
 Github styleguide https://github.com/styleguide
 Java styleguide http://www.oracle.com/technetwork/java/codeconv-138413.html 23

CODE REVIEW

1. Self-code review:
 Automate first level code review
 Each developer should run code review tools to make sure
his code is clean.
2. Peer review:
 Sit in pairs and cross-review.
 Correct and refactor as you review.
 Enforce and automate mandatory peer code review

 Code Review tools:
 Git Pull Requests
https://github.com/features/projects/codereview
 Review Board http://www.reviewboard.org/
 Other tools integrated for instance into
Jira, Phabricator, TFS…

 Use automatic code analysis tools for all languages. Those tools
will be automated with continuous integration. 24
 Measure Code Quality
 Sonar http://www.sonarsource.org/

PAIR PROGRAMMING
 To improve code quality, team focus, collective ownership of

code, spread of knwoledge.
 Do not do it all the time
 Shift pairs frequently

25

DÉPLOIEMENT ET RELEASE
MANAGEMENT

DEPLOYMENTS
 Deployment should be easy, fast and

automatic, on all environments.
 You should have a set of automatic tests to ensure
the deployment went fine.

 Test deployments should be done automatically and
regularly through the continuous integration server.

 Best practices for deployment on Production
 A new release should have a version number.
 Backup before you deploy.
 Run some maintenance and clean up (archive logs…)
before deploying
 Make sure you remove debug mode or development stuff.
 No marketing operation around deployment times (before
and after)
 Monitor the platform closely after deployment. 27
 Never deploy on Fridays. Try and deploy in the morning
or when the traffic is minimal.

RELEASE MANAGEMENT TIPS
1. Deploy and test internally before sending to end-users.

2. Have a release schedule and stick to it.
3. Hold developers accountable for their code changes.
4. Have developers on hand when code is released.
5. Minimize downtime.
6. Reverting to an old version should always be a last resort.
7. Check real-time data after a release is completed.
8. The release process should go as quickly as possible.

28

DEVOPS & CONTINUOUS DEPLOYMENT
« Supporting infrastructure through code. »

« You build it, you run it », Amazon (motto DevOps)

 A complete solution that extends from Dev to Ops makes it possible to answer critical
application delivery questions such as:
 What is in this release?
 Who has tested it?
 What tests have passed and failed?
 Who approved the release?
 Who deployed the release?
 Can I recover easily from a failed release?

 Thus, DevOps is a blend of processes, tools and cultures between the traditional Dev and Ops
teams, intended to increase collaboration between the teams, reduce complexities and
increase the pace at which the whole organization works together to deliver software
applications.

 Go one step ahead: from continuous integration to continuous deployment. 29
 Le processus de déploiement, habituellement jugé délicat, voire risqué, doit devenir un « non-
évènement ».

EXERCICE 1 : MISE EN PLACE D’UNE
INTÉGRATION CONTINUE

1. Faites un fork du projet game of life dans Github

https://github.com/wakaleo/game-of-life
2. Aller sur Buildhives et lancer un build de game-of-
life
https://buildhive.cloudbees.com
3.Modifier le fichier Cell.java dans
gameoflife-core/src/main/java/com/wakaleo/gameoflife/domain
en mettant un + à la place d’une *
4. Refaites un build en échec

31

EXERCICE 2 : REVUE DE CODE
1. Faire une revue de code croisée à l’aide de Git

Pull Request
2. Corriger et faire valider

32

EXERCICE 3 : TESTS
1. Faire un test de performance sur des pages du site

avec Gtmetrix ou Wepagetest
http://gtmetrix.com/
http://www.webpagetest.org/

2. Faire un test de standards W3C
http://validator.w3.org/unicorn/

33

EXERCICE 4 : TEST D’INTERFACE
1. Scripter un test d’interface avec un outil comme

iMacros for chrome ou Selenium IDE sur Firefox
pour tester toutes les pages de votre site
2. Essayer de scripter le login

34

35
Scripter un déploiement en production
EXERCICE 5 : DÉPLOIEMENT
1.

INTÉGRATION CONTINUE
 http://www.wakaleo.com/books/jenkins-the-

definitive-guide
 http://www.infoq.com/articles/MSBuild-1

 Blog Octo : http://blog.octo.com
 http://blog.octo.com/vers-une-usine-de-developpement-
2-0

37

TESTS UNITAIRES ET TDD
 http://googletesting.blogspot.fr/

 TDD
 http://blog.octo.com/tdd-contre-les-montagnes-russes/
 Le livre de référence sur TDD: TDD by Example, Kent Beck
 http://www-igm.univ-mlv.fr/~dr/XPOSE2009/TDD/index.html
 http://www-igm.univ-
mlv.fr/~dr/XPOSE2009/TDD/pagesHTML/ExempleJAVA.html
 http://www.agiledata.org/essays/tdd.html
 http://bruno-orsier.developpez.com/tutoriels/TDD/pentaminos/

38

LOAD & PERFORMANCE TESTING
 http://decrypt.ysance.com/2012/09/tests-de-performances-partie-1-preparation-et-

analyse/
 http://www.clever-age.com/veille/blog/webperf-a-quelle-vitesse-ma-page-se-charge-t-
elle.html
 http://sixrevisions.com/tools/free-website-speed-testing/
 http://sixrevisions.com/web-development/10-ways-to-improve-your-web-page-
performance/
 http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/
 http://samsaffron.com/archive/2012/03/23/sam-s-ultimate-web-performance-tools-and-
resources

39

SECURITY & FRAUD
 http://codeascraft.etsy.com/2012/10/09/scaling-user-security

 http://fr.slideshare.net/nickgsuperstar/fraud-engineering

 http://blogs.atlassian.com/2012/01/13-steps-to-learn-perfect-security-testing-in-your-org/
 http://google-gruyere.appspot.com/

 http://www.pentestit.com/xelenium-security-testing-selenium/
 https://buildsecurityin.us-cert.gov/bsi/home.html
 http://www.clamav.net/lang/en/

40

REVUE DE CODE
 http://blog.octo.com/sonar-loutil-qui-manquait-a-

lusine-de-developpement-net/
 http://www.cellenza.com/publications/la-qualite-des-
developpements-dotnet/
 For PHP:
http://codeascraft.etsy.com/2012/08/10/static-
analysis-for-php

41

RELEASE MANAGEMENT
 http://www.sundoginteractive.com/sunblog/posts/8-lessons-facebook-can-teach-us-

about-release-management
 http://agilewarrior.wordpress.com/2011/05/28/how-facebook-pushes-new-code-live/
 http://ablogaboutcode.com/2011/05/27/recap-and-thoughts-on-the-facebook-deploy-and-
push-process/
http://www.facebook.com/video/video.php?v=10100259101684977

 https://speakerdeck.com/u/ralphbod/p/semi-continuous-delivery-at-new-relic


https://speakerd.s3.amazonaws.com/presentations/5012e0264667b3000200fd4f/SF_Contin
uous_Delivery_Meetup_2012.pdf

42

DEVOPS / CONTINUOUS DEPLOYMENT
 http://www.clever-age.com/veille/blog/le-mouvement-devops.html

 http://blog.octo.com/5-bonnes-raisons-de-deployer-en-continu/
 http://searchsoftwarequality.techtarget.com/tip/Extending-Agile-
teams-with-DevOps-techniques
 http://docs.media.bitpipe.com/io_10x/io_105847/item_562222/DevOp
s%20wo%20Dev%20DOA-final.pdf
 http://fr.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-
cooperation-at-flickr

43

UN PETIT SITE POUR RETROUVER CE COURS
 https://sites.google.com/site/iutbobignyweb/

 Support de formation
 Liens utiles
 Coordonnées
 Formulaire d’évaluation

44

Module 2 IUT Bobigny : Automatisation de la chaîne de production logicielle

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Module 2 IUT Bobigny : Automatisation de la chaîne de production logicielle

Semelhante a Module 2 IUT Bobigny : Automatisation de la chaîne de production logicielle (20)

Último

Último (20)

Module 2 IUT Bobigny : Automatisation de la chaîne de production logicielle