Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lyft iOS tooling infrastructure summary

6ab7ae85b84ebb323fab427b11500742?s=47 Keith Smiley
December 10, 2019

Lyft iOS tooling infrastructure summary

A short presentation about Lyft's iOS tooling infrastructure presented at an informal meetup

6ab7ae85b84ebb323fab427b11500742?s=128

Keith Smiley

December 10, 2019
Tweet

Transcript

  1. None
  2. Background • Currently ~5 apps ◦ bazel query 'kind(ios_application, //...)'

    • Total size of apps ◦ 100% Swift, 0% Objective-C ◦ App code: 8k files, ~550 kloc ◦ Test code: 1k files, ~100 kloc ◦ Generated code: many files, ~300 kloc • Commit activity ◦ ~50 commits per day ◦ ~80 committers per month
  3. • Mac Minis (~100) for Xcode specific jobs, many Linux

    containers (AWS) • On premises for Macs (maintained by us), Cloud for containers • Macs are manually maintained (OS and software, no VMs) • Xcode upgrades are done very soon after each release • Less than 8 minutes PR to merge times CI Build Infrastructure
  4. CI Automation & Resource Management • Buildkite for Macs, Jenkins

    for Linux • Parallel execution • Only build / test changes based on bazel query • Build cache is populated from CI only
  5. • Daily alphas • Weekly release trains • Beta and

    release builds shipped automatically from release branches • Mostly automated with App Store Connect API Release management
  6. Repositories • Git / GitHub everywhere • iOS monorepo, Lyft

    in general is hybrid • Mainly trunk based, some feature release branches • Main challenges ◦ Polyrepos ◦ Feature branches
  7. Build Dependency Management • Dependency managers ◦ Cocoapods, Carthage, Buck

    ◦ ✅ Bazel, Custom ◦ ❄ SPM, Make • How many libs/dependencies does the main app(s) have ◦ ~20 external deps included as precompiled static frameworks ◦ ~600 internal “module” deps per app • How are internal and external dependencies used ◦ External deps have a review process and are kept to a minimum ◦ External deps are not yet in Bazel, we have an in-house tool for this • Main challenges ◦ The custom stuff means has meant implementing some support in Bazel ◦ Xcode integration with bazel
  8. Build System • Build tools ◦ Buck, Gradle ◦ ✅

    Bazel ◦ Xcode/xcodebuild, Custom • Build cache ◦ Currently, Google RBE • Main challenges ◦ Bazel isn’t resilient to cache instability ◦ IDE integration ◦ Need to spin up custom remote execution service
  9. Local IDE experience • Still supporting legacy xcodebuild projects ◦

    Hopefully removed by EOY ◦ Can still generate smaller projects that only include all transitive dependencies • Added focused mode for much smaller projects ◦ Takes <10s to generate project ◦ Supports indexing (lyft/index-import), debugging, testing, most Xcode features ◦ Builds use remote cache, and are debuggable locally! ◦ Disabled CarbonBlack endpoint detection sped up builds by up to 50%
  10. Testing Infra • Test types ◦ XCTest + XCUITest •

    Test metrics ◦ 5k unit tests, runs in multiple jobs on CI ◦ Very few UI tests, non blocking, run in ~10 minutes async • Devices / VM / Simulators testing? ◦ All simulator testing on bare metal Mac Minis • Tests runner/driver ◦ Bazel / xctestrun (xcodebuild) / xctestrunner (xcodebuild) • Main challenges ◦ Async test flakiness ◦ Simulator flakiness
  11. 2019 Progress • Moved to in house Mac Minis •

    Moved to bazel • Got bazel working in Xcode
  12. None