[peterldowns]

Out of curiosity, were you dealing with microservices defined within a monorepo, or microservices each in their own repo? The steps here:

> Build your binaries with the new version. Go through the build errors if any.

> Run all the unit tests with the new version. Go through the test failures.

are a lot easier in a monorepo.

Separately, I've experienced frequent breaking changes in the golangci-lint configuration file. I can't point to a specific instance of this happening but one thing I'd suggest is pinning your version of golangci-lint in development and in CI rather than using "latest".

Golang's backwards compatibility and simplified toolchain is one of my favorite parts about it. Bumping go.mod and downloading the new version of go is usually all it takes!

[crockeo]

Not Hakan, but I was working closely with him at the time. Lyft was on a microservice many-repo setup, and we did pin the version of golangci-lint.

I've found it's actually not so bad to do this kind of work across many repos, as long as you have the tooling to apply the same change to any number of codebases all at once. Our strategy was typically:

- Write an idempotent codemod to do an upgrade. This is easy as long as your configuration is in a declarative language.

- Regularly apply it or update it on all of the applicable repos.

- Merge upgrades incrementally until you've upgraded 100%.

[peterldowns]

Thanks for the insight, that makes sense. What tool did you use for codemods? And do you have any other advice for dealing with many (50+) repos?

[hakann]

Thanks crockeo! You are absolutely correct!

[mseepgood]

> Bumping go.mod and downloading the new version of go is usually all it takes!

Doesn't it auto-download when you bump go.mod nowadays?

[peterldowns]

It might — I use nix to pin my development dependencies, including my `go` binary, so I'm not sure.