Hacker News new | ask | show | jobs
by detaro 2072 days ago
With that tagline, an obvious comparison would be to buildbot. Any specific points in regard to that?
2 comments

Sorry, I'm just coming up to speed on BuildBot in response to your question. There are a lot of tools out there, so apologies if I am misinformed.

Okay. From my quick reading, BuildBot is a nice way to run your tests in parallel. It also has Jenkins-like dependencies, where a successful build can trigger another build.

In Conducto, these parallel and serial steps aren't broken apart, they are combined into a single tree. The tree lets you compose these steps to do bigger and more sophisticated tasks, all within a single build. Check out https://medium.com/conducto/cant-teach-an-old-dag-new-tricks... for more details.

This makes it easy to chain together steps like "Build my artifacts", then "Test them", then "Deploy my app", where each of the steps has more detail.

Also, Conducto has a big focus on debugging that I don't see in BuildBot. In my experience, debugging new features is a major productivity bottleneck for developers, and we built Conducto to make it easy to reproduce errors and solve them quickly, even in long-running pipelines.

I'll keep reading, these are my first thoughts.

Having used conducto's predecessor extensively, I'd say the approach is more generic.

Buildbot seems very specifically geared towards a CI/CD type of workflow (like jenkins/buidbot), with the classic checkout/build/test/deploy(/notify) steps (cf https://docs.buildbot.net/current/manual/introduction.html#c...). Buildbot seems to allow you to customize some steps within the build part, that will run on the same worker.

On the other side conducto is meant to allow you to describe your workflow in python, without forcing you to follow a specific structure. It's up to you to decide how to parallelize things (I can think of build examples where conducto is used to build many objects (ParallelNode), then link). You just define the successsion of serial/parallel tasks that are needed in your automation, rather than trying to make it fit in whatever the makers thought was a proper way to build/test/deploy.