A presentation on how our mobile app development team implemented Jenkins automation server to build iOS and Android apps with cross platform mobile frameworks. Presented at Connect.tech in Atlanta, on October 22nd, 2016. Additional notes: bit.ly/jenkinsnotes

1. CONTINUOUS CROSS PLATFORM
MOBILE DEVELOPMENT WITH JENKINS
ADAM PAXTON

2. PHOTO OP
SLIDES AND NOTES
bit.ly/jenkinsnotes

3. HELLO
ADAM PAXTON
▸ Freelance Mobile App Developer polancomedia.com
▸ iOS, Android, Appcelerator Titanium
▸ Twitter: @adampax
▸ Github: adampax

4. GOALS
WHAT WE WANT TO DO TODAY
▸ Will this help our team?
▸ Pros, cons for using Jenkins
▸ Alternatives
▸ Stuff we learned when setting it up.
▸ Be the boss!

5. RUN THE APP, MAKE SURE THE TESTS PASS, BUILD IT
FOR DISTRIBUTION, UPLOAD IT TO THE BUILD
DISTRIBUTION SERVICE, EMAIL TESTERS. THEN DO IT
ALL AGAIN FOR THE OTHER PLATFORM. AND THEN DO
IT AGAIN TOMORROW FOR THE NEXT FEATURE OR BUG
FIX.
- You, every single day
LET’S GET A BUILD OUT TO TEST…

6. THAT’S NOT THE HALF OF IT
DON’T FORGET…
▸ Pull the latest commit?
▸ Are we doing unit tests? Did those
run?
▸ Where are those keys?
▸ What version of Xcode did we build
on last time?
▸ Which branch?
▸ What’s the password to the
distribution service?
▸ Who needs this version sent to
them?
▸ Where was the build from yesterday?
▸ Who did that build?
▸ What version of the sdk did they use?
▸ Wait, what was that password again?
▸ No, I meant the keystore password,
sorry.
▸ Err, actually, the alias?
▸ I don’t know what it is, either.
▸ How do I run the tests?

7. OK, LET’S MAKE SOMEONE THE
BUILD MASTER.
THAT’S A LOT OF STUFF FOR ALL OF US
TO REMEMBER

8. LET’S HAVE ONE PERSON REMEMBER TO DO ALL THAT STUFF.
PROBLEM SOLVED, RIGHT?
▸ Sometimes multiple builds go out a day (then double that,
since we are cross-platform devs).
▸ Takes our build master’s dev time, and is disruptive.
▸ Multiple people coordinating to do build.
▸ Sometimes we like to go home, or even take vacation!

9. BUILD A ROBOT.
THERE HAS TO BE A BETTER WAY

10. FITTER HAPPIER
AUTOMATE THE TEDIOUS BITS
▸ Identify your workflow
▸ Start with the core ‘build’
▸ Expand forward and backward from there

11. 15 STEPS
CURRENT SETUP
PULL
CHANGES
FROM GIT
TEST IOS
TEST
ANDROID
BUILD AD
HOC
UPLOAD
IPA
UPLOAD
APK
EMAIL
TESTERS
Someone asks me
for a build
…So I ask buildmaster
Build master tells me tests failed,
back to step 1
So who should
get notified?
Do we need to sign the apk?
New devices for the
provisioning profile?

12. THEN A SHEER DROP
MOVING TO THE BUILD SERVER
TEST IOS, ANDROID
BUILD AD HOC
Jobs
UPLOAD IPA, APK
EMAIL TESTERS
Plugin
PULL CHANGES
FROM GIT
Plugin
Build Server

13. THEN A SHEER DROP
INTERACT WITH THE BUILD SERVER
Build Server
Trigger a build
Tell us if build failed
Send out the build!
Excelsior!

14. AUTOMATING WORKFLOW.
WHAT ARE WE REALLY DOING?

15. JIGSAW FALLING INTO PLACE
DOESN’T THIS FEEL FAMILIAR?
▸ We’re refactoring our workflow.
function doBuild(opts, success, error) {
…
}

16. MORNING BELL
HOW TO START A BUILD
▸ Watch for changes to a repository
▸ At regular intervals, every x hours
▸ When another build completes
▸ Via URL, cURL POST
▸ etc.

17. LET DOWN
TELL US IF BUILD FAILED
▸ Usually email logs to us
▸ What test failed?
▸ Blame the last commiter?
▸ Pretty much anything else you want

18. FUL STOP
POST BUILD ACTIONS
▸ Upload to our build distribution service, email users
▸ Publish it?
▸ Trigger another build
▸ Anything else you want

19. OK COMPUTER
WHAT WE NEED
▸ A way to have this stuff done for us
▸ We’re cross platform, so it has to build iOS and Android
▸ Mac for iOS
▸ Android, Java, stuff like that
▸ Whatever our x-platform tool requires, like Node.js
▸ We’re all remote, so has to be remotely accessible

20. NO SURPRISES
HOW ABOUT JENKINS
▸ An automation server
▸ Open source, strong community
▸ Web admin
▸ Insanely flexible (can be overwhelming!)
▸ Probably already a plugin for what you need
▸ jenkins.io

21. I MIGHT BE WRONG
CONS
▸ Every person’s setup is a unique snowflake
▸ Need to maintain the build server
▸ Flexibility can indeed be overwhelming
▸ Ramp up

22. USING JENKINS.
WHAT WORKED FOR US, AND WHAT
DIDN’T.

23. HOW WE USE JENKINS
FIRST, SOME TERMINOLOGY
▸ Job/Project: Any task that you configure Jenkins to run
▸ Build: Result of one run of a job
▸ Build Trigger: How the build is started
▸ Build Step: An action performed by the build, such as run a
command
▸ Post Build Action: What to do when build completes
▸ Workspace: Temporary working directory used for building a job.
▸ Plugin: Extend the functionality of Jenkins w/ core or 3rd party plugins
▸ Pipeline: New(ish)! Define an entire job with a script

24. HOW WE USE JENKINS
INSTALL
▸ A fairly recent Mac w/ latest OS
▸ Install Java 7 or 8 first
▸ Jenkins version 2 LTS
▸ Mac Installer
▸ Installs Applications/Jenkins/jenkins.war
▸ Creates a launch daemon that runs jenkins
▸ Creates a ‘jenkins’ user that runs the jobs/projects
▸ Puts configuration in users/shared/jenkins/home

25. HOW WE USE JENKINS
INSTALL
▸ Our first hurdle: the ‘jenkins’ user
▸ All jobs run as jenkins user, so it needs access to any
sdks, folders, etc.
▸ Can either log in as the jenkins user to set up your dev
environment, or do a lot of ‘sudo su’ and ‘chmod’
▸ Both options can work

26. HOW WE USE JENKINS
MORE INSTALLATION GOTCHAS
▸ Installing developer keys/certificates into keychain
▸ If connected via VNC /remote desktop, the password will fail
silently
▸ Need to connect a physical keyboard to enter pw
▸ Using Node.js with nvm or n didn’t work for us, neither did
Nodejs Jenkins plugin
▸ Installed node.js globally
▸ export PATH=“/usr/local/bin:$PATH" in any build step shell

27. HOW WE USE JENKINS
MOVE THE CORE BUILD
▸ Install your dev requirements
▸ Xcode
▸ Android sdks
▸ X-Platform sdk
▸ etc
▸ Make sure you can run a build manually, start to finish, as
jenkins user

28. HOW WE USE JENKINS
THE WEB UI
▸ localhost:8080
▸ Jenkins 2 has improved the default security settings,
prompting you to set up security during Setup Wizard
▸ Home page shows list of jobs and their stats
▸ Nav column for Managing jenkins, users, etc

29. HOW WE USE JENKINS
ON SECURITY
▸ Not wide-open by default anymore in v2
▸ Create accounts, add to group
▸ For job level access:
▸ ‘Project-based Matrix Authorization Strategy’ sounds a lot more
complex than it really is
▸ Manage Jenkins > Configure Global Security
▸ Then set user/group access on each job
▸ Consider using VPN for remote access

30. HOW WE USE JENKINS
GLOBAL SETTINGS
▸ Manage Jenkins > Manage Plugins
▸ Github plugin (as opposed to just ‘git’ plugin)
▸ Mask Passwords plugin
▸ TestFairy Plugin
▸ wiki.jenkins-ci.org/display/JENKINS/Plugins
▸ Manage Jenkins > Configure System
▸ Configure email
▸ Git settings

31. HOW WE USE JENKINS
CREATING A JOB
▸ New Item > Freestyle Project
▸ Security
▸ Parameterized build?
▸ Prompt user for build inputs, or pass via url args
▸ use them as env variables $paramName
▸ SCM
▸ Build Triggers
▸ Build steps
▸ Post-build actions

32. HOW WE USE JENKINS
CONFIGURING A JOB

33. HOW WE USE JENKINS
SCM AND TRIGGERS

34. HOW WE USE JENKINS
BUILD STEPS

35. HOW WE USE JENKINS
POST BUILD

36. HOW WE USE JENKINS
AFTER A BUILD
▸ Check the build console output.
▸ You will do many of these.

37. HOW WE USE JENKINS
ALTERNATIVES
▸ Bamboo - Atlassian
▸ travis-ci.org
▸ circleci.com
▸ codeship.com
▸ buddybuild.com

38. HOW WE USE JENKINS
NEXT STEPS
▸ Keep automating more items when it makes sense
▸ Ongoing process
▸ fastlane.tools
▸ Pay attention to tests!
▸ Move scripts to source control
▸ Pipelines

39. HOW WE USE JENKINS
WHAT WE LEARNED
▸ Complete automation or CI wasn’t always best for us
▸ Stepped back from having a commit trigger a build all
the way to the user
▸ Making use of URL/params to trigger builds as needed
▸ We keep finding more stuff to automate

40. EXIT MUSIC
TAKEAWAYS
▸ Teams of any size will benefit from automation
▸ Save time!
▸ More consistent testing and distribution
▸ Your workflow and methodologies will fit
▸ Start with the core build, move from there
▸ You will find more ways to automate, improve workflow

41. THANKS Adam
is bit.ly/jenkinsnotes
Cool