The document discusses the introduction of continuous integration (CI) for Android development, emphasizing its benefits such as time-saving, delegated responsibilities, and improved project health monitoring. It outlines key components, tools like Jenkins and Gradle, and their roles in CI processes including automated testing and secure signing. Despite initial setup challenges, the document highlights the overall advantages of CI in enhancing code quality and team communication.

1. Introducing
Continuous Integration
for Android

2. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

3. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

4. Benefits

5. Time is saved and responsibilities are delegated
- less management and oversight, more regularity
Signing credentials safety
On-a-plate project's health statistics
Immediate information sharing among team's members
- success/failure, health
Benefits

6. Drawbacks

7. Initial setup overhead
A server is needed
Drawbacks

8. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

9. Components

10. Components

11. Setup

12. Setup (partial diagram)

13. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

14. Jenkins

15. Well known (has many plugins and good support)
For each project there is one or more jobs
A job's execution is called a build
So called build steps allow to chain multiple actions
A finished build can trigger another job
Each job starts a new emulator instance
Jenkins - key facts

16. Gradle

17. Currently recommended build tool for Android
Highly flexible, very powerful
Transparent configuration format
Unified building process across machines
Dependencies resolved efficiently
Executes so called tasks, e.g. 'assemble', 'test',
'connectedCheck'
Gradle - key facts

18. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

19. Secure signing

20. Well known (has many plugins and good support)
For each project there is one or more jobs
A job's execution is called a build
So called build steps allow to chain multiple actions
A finished build can trigger another job
Each job starts a new emulator instance
Secure signing
Requirements:
each public build should be signed
signing keys for release builds should be kept safe
Secure signing
Solution:
keep release keys only on the CI server
configure Gradle to use release keys if available
(server case)
otherwise make it use debug keys
(dev's computer case)

21. Testing

22. Tests' types:
unit tests
UI tests on an emulator
Testing
Automation gains:
verify codebase frequently to discover new bugs rapidly
run all tests periodically to ensure full regression
compliance

23. Code quality analysis

24. Prevents bugs introduction
Improves future development's speed
Encourages good practices
Automatic inspections save developers' time
High-quality code makes developers happy
Code quality analysis

25. Team notification

26. Push messages to a Slack channel of choice
Post a job status change
E-mail notifications are also available but…
people tend to ignore those (or mark them as spam)
Team notification

27. Distribution

28. Easy APK sharing via Crashlytics (e.g. for QA teams)
Dedicated jobs use only special commits
(e.g. with a release tag)
Distribution

29. Is it worth it?
What's inside - unboxing
Who (and how) is pulling the strings
What can we automate
Summary
Agenda

30. Setup

31. Setup (full diagram)

32. Jenkins
responsibilities

33. Fetches the code
Starts an emulator
Starts code analysis (Sonar Runner)
Invokes Gradle (!)
Collects and publishes artifacts and results
- APKs
- reports: lint, tests
Pushes notifications to Slack
Jenkins - responsibilities

34. Gradle
responsibilities

35. Builds the app (APK)
Signs the app
Performs Android-specific analysis (lint)
Performs unit tests
Performs UI tests
Gradle - responsibilities

36. What's next?

37. Other frameworks for UI tests
- Espresso, Android Testing Support Library
Other tools for continuous integration
- Team City
Direct APKs' upload to Google Play
Running tests on multiple emulators
Customized Slack notifications
What's next?

38. Thank you for your attention

39. mail@codete.com www.codete.com
It’s FREE!
SIGN UP FOR WEBINAR