Survival of the Continuist
- 1. Survival of the Continuist Paul Blundell & Xavi Rigau
- 2. Agenda 1. What we do @novoda 2. A few gotcha’s 3. Q&A
- 3. Agenda 1. What we do @novoda 2. A few gotcha’s 3. Q&A 4. Find info on google/ask us on social network 5. ??? 6. PROFIT!!!
- 4. In the beginning There was nothing.
- 6. Jenkins
- 7. Confidence when code changes
- 10. There is no I in CI team
- 11. Github Oauth sign in ● Makes it easy to sign into the CI ● One less password to remember ● Bonus if you use two factor authentication ● Downside: DDoS
- 12. Unit Testing ● Proves your code works ● Fast to run ● Helps others to understand your code ● Proves others don’t break your code ● Can be used for statistical analysis
- 13. Acceptance Testing ● Instrumented, Connected Testing (cAT) ● Testing real scenarios through connected devices (real or emulated) ● Slow to run / to reproduce ● CI scripting can speed up debugging test cases
- 14. Fuzz || Smoke WebService Testing ● Help your server side team and mobile team work together ● Can point out crazy bugs you’d only see in the wild ● Slow to run ● Limited benefit if you’re committing non-related code
- 15. Sanity checking is boring
- 16. UI/Application Exerciser Monkey ● Send a number of random touch & key events to the app ● Helps you catch weird bugs that only a monkey can reproduce ● Use the seed to reproduce the same scenario ● Use with a minimum of 50k events to get useful feedback ● Let it run nightly on the CI and keep the logcat on a crash ● New Google Play feature (chimpanzee)
- 17. It works on my machine
- 18. Wall Display ● Gives visibility of the status of all projects ● Having a face on a broken build pushes them to fix it ● Filter out non-important jobs ● It’s colour blind friendly
- 19. Our app is tablet only
- 20. ADB power user ● Android command plugin lets you filter devices to run on ● You can filter on device props (brand, model, os version, is emulator, etc.) ● Send input events (automatic app sign in, etc.) ● Install, uninstall, clear prefs, run monkey
- 22. Nightly Builds ● Use nightly jobs to do long running testing ● You can run monkey tests, smoke tests, etc. ● Build and publish the app to alpha groups automatically
- 23. Feature shipping
- 24. Automatic releases to Google Play ● Easily automatable with gradle plugin ● Or DIY using the API directly ● Automate releases to alpha, beta or live
- 25. I want to integrate with the team
- 26. Pull request builder ● Builds code and runs tests on a different branch before it makes it into master. ● Perform actions when the PRB finishes (such as closing the PR if the build fails). ● Customize the comment.
- 27. CI game ● Gives points for adding tests and fixing static analysis issues ● Minus points for breaking the build, adding issues ● Engages the team and makes them care a bit more about fixing those issues
- 29. Use results & analysis graphing on the CI ● You can publish the results of Findbugs, PMD, Lint, Checkstyle and tests on every build ● Evolution of the results over time
- 30. Who put that there?!
- 31. Team chat notifications ● Communicate with your team! ● Use chat integration with Jenkins ● You can choose what events you want to send (build started, finished, failed, back to success, etc.)
- 32. Jenkins notifications ● Complement (or replace) chat notifications with email ● Choose what events you want to send emails for ● Use tags for email lists to have easy filtering (e. g. devs+merlin@novoda.com)
- 33. Want to build faster
- 34. CI nodes and executors ● More nodes means you can have more executors ● You can also create specific environments on each node (only tablets plugged in, only Amazon phones, etc) ● Remote nodes are flaky ● Some setup involved (install SDKs, add SSH keys, etc)
- 35. Parameterised builds ● Gives jobs more flexibility ● Multiple types (checkbox - boolean, raw text, etc.)
- 36. Not everything can be public
- 37. Matrix-based Security Plugin ● Control who can see what job ● Fine control of what actions users can perform in a job (read only, read-write, read but can build, etc.) ● Useful when devs, QA and external people have to use the same job.
- 38. Public facing CI ● Treat open source just like a real project ● Allow contributors to see the state of your build ● Visivle static analysis & test results over time
- 39. Watch out for...
- 40. Log rotation & deleting old builds ● Keep the CI box building fast ● Plugins generate tons of error messages ● Jenkins Jobs * Plugins = tons of logs using disk space.
- 41. JDK6 vs JDK7 builds ● Use the right JDK for your project setup. ● Manually add new JDKs if needed ● We haven’t found a way to force a specific JDK to use when you create a new job.
- 42. Updating build tools/sdks ● Has to be done on all nodes ● Can be done with --no-ui option but it’s a bit tedious ● Maybe can be simplified by using JW’s plugin ● Can be automated as a job in Jenkins #jenkinsception
- 43. Configuration Matrix ● Build the project on the list of nodes you want ● Can be parallel or sequentially
- 44. Updating Jenkins & plugins ● Necessary but scary ● Sometimes plugins aren’t stable enough ● Make sure to test after updating and revert to previous version if something is wrong
- 45. Organise your jobs ● Use views to remove noise from the Jenkins dashboard ● Use specific names to filter or regex ● You can reuse the views for the wall display
- 46. Apex Predator
- 47. WHAT WE WANT (future)
- 48. Xavi Rigau / Paul Blundell @xrigau / @blundell_apps google.com/+XaviRigau / google.com/+PaulBlundell xrigau / blundell Android Software Craftsmen