You are mistaken on many accounts: 1. Bazel/Buck is not just for building, it is a task runner with built in distributed execution and caching. Which is, uh, w

You are mistaken on many accounts: 1. Bazel/Buck is not just for building, it is a task runner with built in distributed execution and caching. Which is, uh, what CI is. 2. You not finding it useful might be because you want to continue to use the same methods and tools yet get different results. Bazel/Buck supports Go and Rust and those just fine (JS is steadily improving as well, I know multiple public companies using it). Now, the DX may be different or non-standard but that's the point...different methods for different results. Of course there are tradeoffs to it not being the standard way to do things for a particular language! 3. You can run postgresql/redis/what have you into the environment with Bazel/Buck, all the companies using these tools do it. Almost everyone wires it up to https://testcontainers.com/ https://testcontainers.com/, see https://www.docker.com/blog/revolutionize-your-ci-cd-pipeline-integrating-testcontainers-and-bazel/ https://www.docker.com/blog/revolutionize-your-ci-cd-pipelin.... 4. For integrating the entire lifecycle, this is how it is set up at most companies...use Bazel/Buck for building the environment, use Bazel/Buck for building, use Bazel/Buck to trigger a deploy, etc. For example, see https://github.com/adobe/rules_gitops https://github.com/adobe/rules_gitops Again, not trying to be rude, just drop info. Your list of pain points in the post is real, but only with certain / older systems or ways of using them. If you look into the newer systems, you'll see that they were largely created to solve those issues!