Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous Cross Platform Mobile App Development using Jenkins Build Server

703 views

Published on

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

Published in: Software
  • Be the first to comment

Continuous Cross Platform Mobile App Development using Jenkins Build Server

  1. 1. CONTINUOUS CROSS PLATFORM MOBILE DEVELOPMENT WITH JENKINS ADAM PAXTON
  2. 2. PHOTO OP SLIDES AND NOTES bit.ly/jenkinsnotes
  3. 3. HELLO ADAM PAXTON ▸ Freelance Mobile App Developer polancomedia.com ▸ iOS, Android, Appcelerator Titanium ▸ Twitter: @adampax ▸ Github: adampax
  4. 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. 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. 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. 7. OK, LET’S MAKE SOMEONE THE BUILD MASTER. THAT’S A LOT OF STUFF FOR ALL OF US TO REMEMBER
  8. 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. 9. BUILD A ROBOT. THERE HAS TO BE A BETTER WAY
  10. 10. FITTER HAPPIER AUTOMATE THE TEDIOUS BITS ▸ Identify your workflow ▸ Start with the core ‘build’ ▸ Expand forward and backward from there
  11. 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. 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. 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. 14. AUTOMATING WORKFLOW. WHAT ARE WE REALLY DOING?
  15. 15. JIGSAW FALLING INTO PLACE DOESN’T THIS FEEL FAMILIAR? ▸ We’re refactoring our workflow. function doBuild(opts, success, error) {
 …
 }
  16. 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. 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. 18. FUL STOP POST BUILD ACTIONS ▸ Upload to our build distribution service, email users ▸ Publish it? ▸ Trigger another build ▸ Anything else you want
  19. 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. 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. 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. 22. USING JENKINS. WHAT WORKED FOR US, AND WHAT DIDN’T.
  23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32. HOW WE USE JENKINS CONFIGURING A JOB
  33. 33. HOW WE USE JENKINS SCM AND TRIGGERS
  34. 34. HOW WE USE JENKINS BUILD STEPS
  35. 35. HOW WE USE JENKINS POST BUILD
  36. 36. HOW WE USE JENKINS AFTER A BUILD ▸ Check the build console output. ▸ You will do many of these.
  37. 37. HOW WE USE JENKINS ALTERNATIVES ▸ Bamboo - Atlassian ▸ travis-ci.org ▸ circleci.com ▸ codeship.com ▸ buddybuild.com
  38. 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. 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. 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. 41. THANKS Adam
 is bit.ly/jenkinsnotes
 Cool

×