I use Brazil on a day-to-day basis and the thing I’d liken it to most is nixpkgs. Personally, I think that most of the benefits of Brazil can be realized with something like target/lorri and Cargo-style build systems.
I’m not sure if I understood the “version set” concept completely. It seems to similar to Cargo.lock files where the transitive closure of your dependencies is recorded. However…
When version sets are imported into Apollo, all of the test and build dependencies are stripped away and the remaining graph is passed in.
That sounds like it additionally stores the information which dependencies are only used for testing and build purposes but unnecessary for deployment. That sounds more like package manager like Nix or Apt. In some sense, Amazon software is treated like an extended Linux distro?
If you create a package, say the IDL for your service API or config for clients to connect, you specify the interface version (say, “1.0”). Every time you build, the generated package is given a concrete build version (“1.0.1593214096”). That build version is what’s stored in the version set for each package node. Developers never manage the build version either as an author or consumer.
I’m not sure if I understood the “version set” concept completely. It seems to similar to Cargo.lock files where the transitive closure of your dependencies is recorded. However…
Yup, you can think of version sets are a server-managed Cargo.lock which enable some neat things with the internal CI/CD system such as “where has this commit been deployed to?”. From a development standpoint, version sets are also tied to workspaces, which consist of several cloned packages. You can think of workspaces akin to Cargo workspaces.
That sounds like it additionally stores the information which dependencies are only used for testing and build purposes but unnecessary for deployment.
That’s right.
That sounds more like package manager like Nix or Apt. In some sense, Amazon software is treated like an extended Linux distro?
It really depends on the language, but that’s not wholly inaccurate. With npm or Cargo-based projects, language-idiomatic tooling is used for builds with Brazil serving system dependencies. At that point, it’s less a build system and more a packaging and artifact provenace system.
That sounds unlike any package manager I know.
Yup, that part is unique due to the norms around package versioning (you don’t ever cut a new version.)
My bad. In this instance, releasing a package at a new version. A bump from 1.0 to 1.1 is considered to be a really big deal and is highly discouraged. Brazil treats any version bump as breaking change, as version numbers are treated as opaque strings.
How are security issues in dependencies handled? Does the insecure version get blacklisted and consumers are forced to move to a later version, or do the dependency authors backport the fix to older versions?
When I was there, such things would be surfaced in various interfaces, but if it was truly critical it would require one team going and wrangling all the other teams into updating their version sets (and possibly doing the work for them).
The upside of version sets is that each team owns their whole dependency chain and get to choose when they want to take changes from other teams - it gives every team significant independence. The downside is that version sets accumulate cruft (good luck fully rebuilding one; quite possible some of the artifacts you’ve been using for years no longer compile), and if you vend libraries to other teams you can expect a long tail of old versions in use. It’s very difficult to go make the kind of large, company-wide crosscutting changes that you can at eg. Google/FB, and that includes things like compiler/runtime upgrades.
I don’t really think there’s a better or worse between the Amazon and Google/FB style build/deploy/source control systems, it’s primarily a reflection of the org/team structure and what they prioritize - there’s tension between team independence/velocity and crosscutting changes that optimize the whole codebase.
There seems to be little information about it available although the people on the linked page give it a great rating:
what Google, Facebook, and most other companies of comparable size and larger do is at best objectively less good and at worst wasting millions of dollars of lost productivity,
Once you understand the build and deployment tools you first wonder how you ever did anything before and then start to fear how you’ll do anything once you leave.
Until a few months ago I was one of the internal “owners” of the “live” versionset they mention here, and now I work with the Apollo product instead. It’s probably not a huge stretch to say that I know the capabilities and limits of the system better than most Amazonians.
The gist is … pretty accurate? It’s interesting to see how different teams use or choose not to use the capabilities that Brazil offers. I have to be NDA-aware, but if you have specific questions, I’m more than happy to answer them.
I have fond memories of my brief time at Amazon. Brazil is not one of them. It’s not even that I can say it’s fundamentally bad, but it is a lot of complexity. The best things I can say about it are that it does the job and it means no-one has to invent something to do that job.
I use Brazil on a day-to-day basis and the thing I’d liken it to most is nixpkgs. Personally, I think that most of the benefits of Brazil can be realized with something like target/lorri and Cargo-style build systems.
I’m not sure if I understood the “version set” concept completely. It seems to similar to Cargo.lock files where the transitive closure of your dependencies is recorded. However…
That sounds like it additionally stores the information which dependencies are only used for testing and build purposes but unnecessary for deployment. That sounds more like package manager like Nix or Apt. In some sense, Amazon software is treated like an extended Linux distro?
That sounds unlike any package manager I know.
Yup, you can think of version sets are a server-managed
Cargo.lockwhich enable some neat things with the internal CI/CD system such as “where has this commit been deployed to?”. From a development standpoint, version sets are also tied to workspaces, which consist of several cloned packages. You can think of workspaces akin to Cargo workspaces.That’s right.
It really depends on the language, but that’s not wholly inaccurate. With npm or Cargo-based projects, language-idiomatic tooling is used for builds with Brazil serving system dependencies. At that point, it’s less a build system and more a packaging and artifact provenace system.
Yup, that part is unique due to the norms around package versioning (you don’t ever cut a new version.)
What do you mean by “cut”?
My bad. In this instance, releasing a package at a new version. A bump from 1.0 to 1.1 is considered to be a really big deal and is highly discouraged. Brazil treats any version bump as breaking change, as version numbers are treated as opaque strings.
How are security issues in dependencies handled? Does the insecure version get blacklisted and consumers are forced to move to a later version, or do the dependency authors backport the fix to older versions?
When I was there, such things would be surfaced in various interfaces, but if it was truly critical it would require one team going and wrangling all the other teams into updating their version sets (and possibly doing the work for them).
The upside of version sets is that each team owns their whole dependency chain and get to choose when they want to take changes from other teams - it gives every team significant independence. The downside is that version sets accumulate cruft (good luck fully rebuilding one; quite possible some of the artifacts you’ve been using for years no longer compile), and if you vend libraries to other teams you can expect a long tail of old versions in use. It’s very difficult to go make the kind of large, company-wide crosscutting changes that you can at eg. Google/FB, and that includes things like compiler/runtime upgrades.
I don’t really think there’s a better or worse between the Amazon and Google/FB style build/deploy/source control systems, it’s primarily a reflection of the org/team structure and what they prioritize - there’s tension between team independence/velocity and crosscutting changes that optimize the whole codebase.
There seems to be little information about it available although the people on the linked page give it a great rating:
The kind of open-source variant is https://qbtbuildtool.com/
QBT Build Tool was in fact written by the author of the linked Gist (cmyers).
Until a few months ago I was one of the internal “owners” of the “live” versionset they mention here, and now I work with the Apollo product instead. It’s probably not a huge stretch to say that I know the capabilities and limits of the system better than most Amazonians.
The gist is … pretty accurate? It’s interesting to see how different teams use or choose not to use the capabilities that Brazil offers. I have to be NDA-aware, but if you have specific questions, I’m more than happy to answer them.
I have fond memories of my brief time at Amazon. Brazil is not one of them. It’s not even that I can say it’s fundamentally bad, but it is a lot of complexity. The best things I can say about it are that it does the job and it means no-one has to invent something to do that job.