Skip to main content
Sometimes it’s Bazel that should change - things like writing to the source folder, the choice of working directory for a test, having a filesystem layout in a certain way. We want to avoid changes that break the legacy build, and don’t want developers to have an impression that Bazel requires code changes that are really just different idioms. If the code does have to change, maybe it can be in a superficial way. For example you could add comments like Gazelle directives that inform the tooling without making any load-bearing changes that could break things. Dependencies are an important case as well. We shouldn’t change versions of any third-party library just because Bazel is managing them.

​
Leave few fingerprints

As an infrastructure team, you want to make sure product engineers own their own code during and after a migration. You also want to touch only the build system, while leaving the owners of the code to make modifications. You can run a tool which changes the code in known-safe ways (like running a formatter), then attribute changes to that tool rather than yourself. If you’re editing a bunch of code, you probably didn’t follow the “leave the code alone” principle.