The fine art of deploying web apps online

Nous savons tous coder, mais nous ne sommes pas tous à l'aise pour déployer.
La livraison d'une application est souvent un peu traumatique, mais c'est pourtant loin d'être une fatalité. Quelques outils essentiels, un peu de communication et d'anticipation vous feront oublier à tout jamais les sueurs froides du 'glisser-déposer' via FTP.
La pratique du Delivery Driven Development n'est pas réservée à de grosses entreprises : nous l'appliquerons ici à des projets web à petits budgets et courts délais, typiques d'une agence web. Nos objectifs : Mettre en prod' beaucoup plus souvent, rattraper rapidement une mise en ligne qui a planté, et mieux partager les connaissances et les responsabilités entre collègues.
En améliorant et en automatisant le processus de livraison des applications web, votre équipe gagne en assurance, se réconcilie avec les infogéreurs, conquiert la confiance du chef de projet, l'estime du client final, mais surtout elle dort l'esprit tranquille.

DevFest Nantes 2014

Transcript

2. Deployment
 Adventures
3. var me = { "user": "Ronan" , "age": 37 , "origin": "Brittany" , "twitter": "@arno_u_loginlux" , "repo": "github.com/ronanguilloux" , "work": "cto@lespolypodes.com" , "tags": [ "dad" , "bearded web developer" , "open-source enthusiast" , "web agency veteran" ] }
4. Agence Innovation Numérique Nantes
 
 #hack #frontEnd #innovation #accessibilité
5. Developers?
 Deliverers!
6. — Let’s… D E P L O Y Y Y!!!
7. F*cking well deployed.
8. « big bad deployments fatigue »
9. — « Chief, it failed. »
10. Goal #1 
 • Keep it usual and common
11. — « Are you a reliable person ?
12. alone & resourceful Developer in web agencies
13. Delivering middle-size web apps elapsed time: 0.5 to 5 hours. 
 
 long, unpredictable & stressful
15. 0: write & run deployment (rehearsal mode)
 1: write & run [unit/func/behav/*] tests
 2: start coding! DDD Work Process
16. Collaboration Specs github.com/polypodes/Collaborate
17. In a manual deployment case
 we all know exactly what to do, in which order

18. Front-end hipsters whims
 that change every 2 weeks.
19. Goal #2:
 • All my team must be part of it.
20. Silver bullet, anyone? Deployment Automation Tools
21. Choices that matters #1 Description formats
 (Yaml / Json / XML, etc.) 
 
 Vs 
 Programming languages (Ruby, Js, etc.)
22. « If you’re doing automation,
 you’re already doing
 something right.
 
 It’s not about how you do it. » (Shaun Dunne, medium.com) « Grunt vs Gulp vs Make vs Rake vs Jake vs Cake vs Brunch vs Ant vs Maven vs Bash vs You… »
23. DB Structure Design 
 (normalized Versus document-oriented) 
 
 DB Data Model Type Entity–attribute–value (Drupal / eZPublish / Magento, etc.)
 Versus Standard relational
 (i.e., one column per attribute) Choices that matters #2
24. $~: mysqldump \ --skip-comments \ --skip-extended-insert \ -u root -p database1.sql > schema1.sql (x2) $~: diff schema1.sql schema2.sql
 $~: mysqldiff schema1.sql schema2.sql $~: php app/console \
 doctrine:migrations:migrate $~: pgdiff schema1.sql schema2.sql
25. Anticipation is the key
26. Let’s write a simple build script
27. #!/bin/sh echo "Fetching tools + vendors..." npm install bower install npm install -g gulp gulp echo "dumping actual db..." mongodump --out /var/data/backup/ echo "installing assets + uploads dirs" mkdir -p web/uploads ln -s dist/assets web/assets
28. Cool & simple things always remain cool & simple. me@server$~: ./build.sh building... done. me@server$~:
29. Makefile simple & effective.
30. # Makefile (= shell + targets + task sets) vendor/autoload.php: @composer self-update @composer install —optimize-autoloader integration: @echo "building front-end assets..." @npm install && gulp @ln -s dist/assets web/assets build: vendor/autoload.php integration @git pull origin $(BRANCH) @php app/console cache:warm tests: build fixtures unit behavior .PHONY: integration build tests
31. Everyone in the team should now be a deployer. me@server$~: make Ready to install. 
 me@server$~: make install Installing... Done. me@server$~:
32. Making is cool. me@server$~: make me@server$~: make build me@server$~: make deploy me@server$~: make update me@server$~: make whatever me@server$~:
33. (OK, OK, this is all largely inspired by Capistrano directories structure) ➜ myApp tree !"" [me 19] current -> releases/2014-06-24 !"" [me 68] Makefile !"" [me 238] releases # !"" [me 68] 2014-04-20 # !"" [me 68] 2014-05-02 # !"" [me 68] 2014-05-15 # !"" [me 68] 2014-06-01 # $"" [me 136] 2014-06-24 # !"" [me 68] src # $"" [me 136] web # !"" [me 0] index.php # $"" [me 16] uploads -> ../../../uploads
 $"" [me 238] uploads
 11 directories, 1 file
 ➜ myApp
34. github.com/polypodes/Build-and-Deploy
35. Before automation
36. After automation
37. Goal #3:
 • Keep building & deploying all day long.
38. Discovered a first nice rule: Do not always ask for permissions.
39. Only announce changes
 that just already happened Discovered a second nice rule:
40. (Third Age tombstone phrase, Lothlorien) « There are only two hard things
 in Computer Science: 
 cache invalidation
 and naming things. »
41. Semantic Versioning
 As A Delivery Process & One Roadmap to Rule Them All v2.4.1
 
 « major.minor.bugfixes »
42. Again,
 we didn’t ask for permissions.
 
 But people quickly adopted it. Let’s stay quiet & carry on…
43. Web Quality Checklist that now should become a test suite
45. Is you Company hackable ?
46. Ronan Guilloux @arno_u_loginlux
 github.com/ronanguilloux Thanks! Questions ?