reliza-cli VS shipit-engine

We currently provide accurate lead time and deployment frequency calculation capability via Reliza Hub - https://relizahub.com (operating in public preview). Since we track when each piece of code gets deployed to each environment and each instance. Other metrics are on our roadmap.

You then either leverage getlatestrelease functionality of reliza-cli - https://github.com/relizaio/reliza-cli#6-use-case-request-latest-release-per-project-or-product to request approved image or you can use replacetags functionality over your Dockerfile which would replace base image with the one approved - https://github.com/relizaio/reliza-cli#74-use-case-replace-tags-on-deployment-templates-to-inject-correct-artifacts-for-gitops-using-environment

Note, we have recently released a new replacetags functionality (https://github.com/relizaio/reliza-cli#74-use-case-replace-tags-on-deployment-templates-to-inject-correct-artifacts-for-gitops-using-environment - going to add tutorial soon) so that you don't need to use templating language inside your helm charts or manifests and instead it would just parse raw base yamls into correct images per each environment.

We're building Reliza Hub for this purpose - https://relizahub.com

Note, it's somewhat outdated and we're working on a new one based on new replacetags functionality - https://github.com/relizaio/reliza-cli#72-use-case-replace-tags-on-deployment-templates-to-inject-correct-artifacts-for-gitops-using-instance-and-revision

For example: shipit was a homebrew deployment system Shopify made, and they open-sourced it because there's nothing about how they ship their code that's a trade secret or worth hiding.

> Usually that was in the form of long-running network calls.

That's why doing a network call to another service in the middle of a request is pretty much banned from the monolith. Anything that doesn't have a strict SLO is done from background jobs that can take longer, be retried etc.

Now you mention FedEx so I presume you were working on the shipping service, which by essence is kind of an API bridge so it's probably why it was deemed acceptable there, but that's far cry from what a typical Rails app look like, except maybe in companies that do a lot of micro-services and are forced to do inline requests.

> that's not a use case that Ruby/Rails are built to elegantly handle.

I'd argue the contrary, the elegant way to handle this is to perform these calls from background jobs. Look at shipit [0] for instance, it's syncing with the GitHub API constantly but doesn't do a single API call from inside a request cycle, every single API call is handled asynchronously from background jobs.

[0] https://github.com/Shopify/shipit-engine/

My team is evaluating different deployment tools to replace our homegrown solution.

There are plenty of continuous integration tools (GitHub Actions, CircleCi, etc.), but adding deployment aware logic like canary deployments and having an audit log of deploys requires adding lots of code which I'd rather not maintain.

I'm looking for tools focused on code deployment. A quick search turned up shipit (https://github.com/Shopify/shipit-engine) and teletraan (https://github.com/pinterest/teletraan).

Are there other open-source deployment tools like those projects?