I saw Slack has something called Checkpoint
Ask HN: Why do some companies build their own CICD orchestrators?
1–10 of 18 posts
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#2There's an article here explaining one reason why they put Checkpoint in front of Jenkins: https://slack.engineering/circuit-breakers/
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#3Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/
That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD system out there except Jenkins and Buildkite, and both of them a pretty horrible at it unless you spend lots of time with custom scripts. At some point it will become easier to rewrite entire system rather than try to fight existing one.
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#4I built one for a client. It was a rocketchat bot taking commands for making a release of a specific tag or latest master branch, a revert, showing what is currently deployed and printing a commit log vs previously deployed commit. Worked like a charm. Was a set of ansible scripts called by node. No need for anything fancy.
Oh and it always expected a confirmation.
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#5Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/ That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD…
No post body was provided.
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#6Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/ That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD…
I would think running something within a Docker container is running it natively?
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#7Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/ That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD…
This is possible with github actions. Have one job create a matrix of other jobs for each of your runners.
Use self hosted runners if you are worried about costs or have special requirements.
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#8Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/ That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD…
This is possible with github actions. Have one job create a matrix of other jobs for each of your runners. Use self hosted runners if you are worried about costs or have special requirements.
There are limits on build queue sizes unless you buy the enterprise plan. Also doesn't work if you are not hosting code on GitHub
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#9Checkpoint is a deploy system, not a CICD. A quick Google finds a nice description of it: https://slack.engineering/deploys-at-slack/ That said, once you step away from webapp world, a lot of times all existing CI/CD systems are pretty terrible. For example we have pre-merge tests that need a few tens of cpu-hours spread across a dozen machines, and running natively (no docker). This rules out pretty much every CI/CD…
I would think running something within a Docker container is running it natively?
How do you build a container from inside a container? Answering this gives you one example of a difference
Re: Ask HN: Why do some companies build their own CICD orchestrators?
#10It has been tried, for example making diagrams in Rational Rose and generating C++ code from that. Then I assume filling in the code "details" manually. Probably someone else can comment on how that has worked.
That was before agile or TDD were such big things.