Keynote by Jeff Atwood

Learning from failure is the best Books:

  • bad blood
  • postmortem from game developers

to learn from mistakes -> take notes

safety system test?

Project Updates + Q&A

Based in Munich + some in the valley

https://github.com/bazelbuild/bazelisk == gradlew https://github.com/bazelbuild/starlark new name for Bazel language https://github.com/bazelbuild/rules_jvm_external for maven migration

https://github.com/bazelbuild/bazel-bench performance tracking tool build profiler compatible with Chrome DevTools bazel aquery -> query actions

Android rules were rewritten from Java to Starlark https://github.com/bazelbuild/rules_kotlin maintained by https://github.com/cgruber in Square

A lot of questions about roadmaps, seems like it’s difficult to adopt Bazel ideally if there’s no idea when specific things will be improved/things.

Building Self Driving Cars with Bazel in BMW

23M LOC 2k developers 20k CI builds per day C++, Python, C, Shell, Java, Go Cloud based CI virtual mono-repo

why they take Bazel:

  • Sandbox built in (privacy rules)
  • incremental builds, no clean, tests are cached and executed incrementally
  • frozen dependency management

Remote caching working awesome but remote execution hard to setup, they’re using https://github.com/buildbarn

they’re using git-submodules to have like a mono-repo CI build always against HEAD of all repos (–> no delayed integration) CI build everything (90% is cached) they use Zuul (by OpenStack) support dependant merging of PR from diff. repos

Six learnings in moving to a Bazel-based CI system

WIX CI 5M LOC +1K repos 2k+ maven modules push to feedback 5/10 mn release few hours

Use a migration tool for easy migration, like: Easily migrate your JVM code from Maven to Bazel: https://github.com/wix/exodus

local dev != CI, monitor both to know if yoou didn’t break one keep the old CI so you can migrate when ready

to have smooth migration, they migrated 50 repos smoothly. I have 1 internal dep:

  • is it migrated? Consume source, otherwise consume maven binary

Lessons from Our First 100,000 Bazel Builds

Slides and notes: http://bit.ly/hungrybazel By Kevin Gessner, Etsy.

Advise: start to learn about migration key points.

Transitive dependencies has to be resolved, its a pain by hand… They’re using a maven->bazel script: https://github.com/johnynek/bazel-deps but should be replaced by the official maven rules.

More bazel granularities -> more parallelism.

Circular dependencies are not possible, so clean them gradually…

For easy use, write wrapper that people can be familiar:

  • build.sh for ./gradlew build
  • runTests.sh for ./gradlew test and so migrate to bazel internally is easy.

A .bazelversion file + bazelisk + in build:

versions.check(
    minimum_bazel_version="1.0.0"
)

remote cache is awesome but not easy to setup, but awesome for any artifacts, even test results.

http://github.com/jin/awesome-bazel

About their deployment, they’re using:

Starlark is scary http://docs.bazel.build/versions/master/skylark/aspects.html it’s hard to learn BUT worth it. genrules is magic glue for sticking things together.

Migrating Lyft-iOS to Bazel

TODO

Gradle to Bazel

Dockerfile is better in Bazel, working in // and hermetic

Bazel cannot publish maven artifacts, there’s community rules: https://github.com/graknlabs/bazel-distribution

Gradle:

  • Spotbugs (Findbugs successor)
  • PMD
  • checkstyle

Bazel:

Gradle evolved with Plugins and custom tasks Bazel with rules, tool chains and platforms