Bitrise: Make iOS Builds Faster - Tokyo 2019 March - Cookpad meetup
- 1. Introduction to Bitrise Hendrik Haandrikman VP of Growth [email protected] Hhaandr Introduction and iOS onboarding Tamas Bazsonyi Global head of Support Bazsca
- 2. THANK YOU
- 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. 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. 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. 日本での採用開始！ Budapest, HU Remote (JP?)London, UK
- 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. 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. 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. Make iOS Builds Faster Faster iOS Builds on Bitrise.io Viktor Benei [email protected] Tokyo, 2019 March
- 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. 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. 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. 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. 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. 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.
- 18. 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
- 19. 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/
- 20. Carthage - GitHub Access Token GitHub Personal Access Token
- 21. 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.
- 22. 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.
- 23. 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
- 24. 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.
- 25. 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
- 26. 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
- 28. 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
- 29. Thank you! Twitter: @viktorbenei I’ll share the slides on my Twitter.