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

Lyft iOS tooling infrastructure summary 2019

Avatar for Keith Smiley Keith Smiley
December 10, 2019

Lyft iOS tooling infrastructure summary 2019

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

Avatar for Keith Smiley

Keith Smiley

December 10, 2019
Tweet

More Decks by Keith Smiley

Other Decks in Technology

Transcript

  1. 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
  2. • 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
  3. 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
  4. • Daily alphas • Weekly release trains • Beta and

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

    in general is hybrid • Mainly trunk based, some feature release branches • Main challenges ◦ Polyrepos ◦ Feature branches
  6. 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
  7. 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
  8. 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%
  9. 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
  10. 2019 Progress • Moved to in house Mac Minis •

    Moved to bazel • Got bazel working in Xcode