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.

Bitrise: Make iOS Builds Faster - Tokyo 2019 March - Cookpad meetup

3,443 views

Published on

Bitrise: Make iOS Builds Faster - Tokyo 2019 March - Cookpad meetup

Published in: Technology
  • Be the first to comment

Bitrise: Make iOS Builds Faster - Tokyo 2019 March - Cookpad meetup

  1. 1. Introduction to Bitrise Hendrik Haandrikman VP of Growth rik@bitrise.io Hhaandr Introduction and iOS onboarding Tamas Bazsonyi Global head of Support Bazsca
  2. 2. THANK YOU
  3. 3. Enabling mobile app developers to do their best work What do we do? Bitrise automates mobile app integration, testing and deployment to make developers more consistent, faster and freeing up their time and talents for the work that matters. Bitrise Founding Founded in 2014 by app development agency alumni (Bitfall), looking to improve their own process. Y Combinator backed with $ 3.5M in funding. By the numbers 100K developers 15K+ unique apps 1M+ builds / month 50% of mobile unicorns Headquarters Headquartered in Budapest, Hungary, office in London, remote in USA, France & more.
  4. 4. Bitrise and Unicorns Many of the world’s most highly valued startups use Bitrise to maximize developer efficiency, minimize time wasted onboarding and ensure that developer time is spent on tasks that bring the company a competitive advantage
  5. 5. Bitrise and Japan Japan is our #2 market worldwide.. Over 20% of our first 1.000 sign-ups originated there and today, some of Japan’s most well- known developers build on Bitrise.
  6. 6. 日本での採用開始! Budapest, HU Remote (JP?)London, UK
  7. 7. Adding a new iOS project Scanner is open source: https://github.com/bitrise-core/bitrise-init Used in the Step: https://github.com/bitrise-steplib/steps-project-scanner Used in the plugin: https://github.com/bitrise-core/bitrise-plugins-init
  8. 8. iOS code signing codesigndoc You need the development certificate and provisioning profile even for App Store signing - this is one of the most common issues Use our codesigndoc open source tool Analyses the project and collects signing files from your Mac Guide: https://devcenter.bitrise.io/code-signing/ios- code-signing/collecting-files-with-codesigndoc/
  9. 9. iOS Auto Provisioning Step analyses the project during the build Connects to Apple Developer Portal, generates the right profile(s) and downloads them Needs the certificate (private key) - codesigndoc can be used for getting that! Guide: https://devcenter.bitrise.io/code-signing/ios- code-signing/ios-auto-provisioning/
  10. 10. Make iOS Builds Faster Faster iOS Builds on Bitrise.io Viktor Benei viktor.benei@bitrise.io Tokyo, 2019 March
  11. 11. Quickest -> More complex Starting from easiest, which takes the least amount of time to configure, progressing towards more advanced and complex techniques which might require project or more significant configuration changes.
  12. 12. Elite machines No change required anywhere in the config or in your project. Usually 20-50% faster (depends on the project, you get 2x the CPU and RAM but not network or I/O).
  13. 13. Linux stack Use Linux stack when possible - newer generation CPUs compared to the aging MacPROs and more RAM. SPM based projects, e.g. Swift server apps or CLIs.
  14. 14. Cache steps https://devcenter.bitrise.io/caching/about-caching/ Cache:Pull and Cache:Push Use Bitrise steps, those have built in support. If you use another tool instead, like fastlane, it works, but you'll have to specify the dirs/files to cache. Another example: CocoaPods & Carthage steps (dependency management steps in general)
  15. 15. Keep the Cache small If you set custom Cache paths make sure you only include the files & dirs you need, to keep the cache size small. Smaller cache is faster (download, uncompress, compress, upload). You can check the cache content on Settings tab, you can download the caches from there too for inspection.
  16. 16. Parallel build - https://devcenter.bitrise.io/builds/triggering- builds/trigger-multiple-workflows/ - https://blog.bitrise.io/start-multiple-builds-with-the- same-trigger Needs 2+ concurrencies. Today it uses Steps, lower level support is coming soon.
  17. 17. Parallel build Few ideas: - Do Xcode Test, Xcode Analyze and Swift Lint in parallel - Split your Xcode Test into multiple Targets/Schemes - Run Test and Archive for internal QA in parallel
  18. 18. Bitrise Device Testing feature Use Bitrise built in (Firebase) Device Testing if you want to run the test on multiple devices. https://devcenter.bitrise.io/testing/device-testing-for-ios/
  19. 19. Carthage - GitHub Access Token GitHub Personal Access Token
  20. 20. COMPILER_INDEX_STORE_ENABLE =NO https://twitter.com/steipete/status/1100404024224804871 - xcode-test: inputs: - xcodebuild_test_options: COMPILER_INDEX_STORE_ENABLE=NO Only helps Debug/non release builds.
  21. 21. Use latest Bitrise step versions We add both reliability and performance optimisations. E.g. latest Xcode Test step uses headless mode by default, which can make the tests significantly faster.
  22. 22. When deploying multiple .ipa files (e.g. one for ad-hoc and another one for app-store release) use only one Xcode Archive & Export for iOS (https://www.bitrise.io/integrations/steps/xcode-archive) step and then the Export iOS and tvOS Xcode archive step (https://www.bitrise.io/integrations/steps/export- xcarchive) for additional .ipas. Multiple IPAs in the same build
  23. 23. Git Clone: set fetch size to 1/10/20 If the history isn't enough, e.g. PR build, the step will automatically fetch more. For commit based builds it can save a lot of time. Clone Config > Limit fetching to the specified number of commits - If most of your builds are PR builds with multiple commits in it, set it to 10-20 (average commit length in your PRs). - You can’t use this if you depend on the whole git history to be available, e.g. for tagging, that’s why this isn’t the default.
  24. 24. Boot the iOS Simulator at the start of the build, so that it will be booted & ready by the time you run your tests in it. Our Xcode Test step has a related optimization: it starts to boot the simulator before it'd compile & run the test. Pre-boot iOS Simulator
  25. 25. Remove unused/unnecessary steps. E.g. use GitHub protected branch & enable Require branches to be up to date before merging to not to allow push to master (and make sure you enable Pull Request builds on Bitrise and require the /pr status check on GitHub), then remove the Test steps from the deploy workflow as builds will have to go through PR first. This way the PR can only be merged if it already passed the tests*. *Bitrise PR build tests the pre-merged code, merges the PR source into its target during the build to test the code state after merge. Remove unnecessary steps
  26. 26. Collection of tips - https://devcenter.bitrise.io/tips-and-tricks/optimize- your-build-times/ - Track function compilation time: http://khanlou.com/2016/12/guarding-against-long- compiles/ - https://github.com/fastred/Optimizing-Swift-Build- Times - https://medium.com/@bitrise/60-faster-builds-force- xcode-to-use-caching-on-bitrise-af8979ca39a6
  27. 27. Thank you! Twitter: @viktorbenei I’ll share the slides on my Twitter.

×