When Mitchell Hashimoto drove a wave of enthusiasm about Buildkite, my editor suggested I take a look even though it's not an open source (my usual beat for The Stack). After all, CI/CD isn't usually something anyone, especially developers, gets enthusiastic about rather than frustrated.
Buildkite strikes a balance between developers and platform teams, Sarah Bassett from AWS (in Buildkite's native Australia) told me; it gives them the separation of concerns a mature devops practice needs.
The core of Buildkite is the hybrid control plane that lets you run build agents on your own or rented compute is a flexible approach (although the pricing around that has been challenging and is about to change again).
in fact, dynamic pipelines was an accident from the constraints of having a cloud control plane that can't read your repo for security reasons: it was the customers who realised they could use that to make decisions about not just build efficiency but velocity, testing coverage and cost in flight.
@wallyqs.bsky.social from the NATS project Waldemar Quevedo was even able to get away from YAML; he's another Buildkite fan and told me how NATS uses it. The Bazel team are also big fans...
About the time this piece got published, I was reading a writeup of a project that changed languages because build and compile time was just too slow for the velocity of agent-written code pushes
that's exactly the kind of tradeoff the most sophisticated Buildkite users are making with dynamic pipelines that let them base CI/CD time decisions about testing and pushing code on what happens inside the CI/CD pipeline.
Everyone has the same hockey stick graphs on code activity as GitHub and is making decisions about how to deal with that and ship the best code they can at the right speed. Buildkite is one way to shift those decisions left: they just need to figure out how to have the pricing reflect that value.
CI/CD
coding agents
shift left
developer productivity
Bazel
hybrid cloud
test philosophy