A deep dive into Jenkins Continuos Integration, how you can enable your team to collaborate more, run tests and configure the robots to do all the things for you. Also talking about caveats around automation, testing on real devices, usb hub woes and more.
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
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)
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
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
24. Automatic releases to Google Play
● Easily automatable with gradle plugin
● Or DIY using the API directly
● Automate releases to alpha, beta or live
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
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)
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)
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
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
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
