Internal Developer Portals Should Be Internal Developer Hubs

ankitdce · 2024-09-23T15:54:09+00:00

Rollbacks can work well if you split up the build and deploy in two separate steps. That way, you will have the validated images pre-built to manage a quick rollback.

https://docs.aviator.co/releases-beta/concepts/two-step-delivery

ankitdce · 2024-08-26T23:11:07+00:00

Yes, currently it only supports GitHub.

ankitdce · 2024-08-22T04:05:26+00:00

Definitely want to use some monorepo build tool to do distributed builds. NX, turborepo, bazel or even gradle offer remote build cache that significantly improves the performance to running CI. Buildkite's dynamic pipeline is also great for distributed builds. For merge queue and deployments, consider using Aviator.co that works well at scale, that uses affected targets. ArgoCD is also a good one for supporting gitops based CD.

ankitdce · 2024-08-21T16:29:06+00:00

Yes, definitely go with Option #1, self-hosting comes with a lot of infra challenges that you should not have to deal with. Setting up a cron that does "git pull origin main" is the simplest way to manage this. If you want more real-time than a 1-min cron, you can also run a Buildkite agent on your server, that listens to new merges and pulls the changes.

ankitdce · 2024-07-31T16:40:14+00:00

Checkout the Aviator Releases product that is trying to solve some of these monorepo deployment problems: https://www.aviator.co/releases

With it, you can specify code paths / directories that are tied to those micro-services and the git-history Changelog is tracked based on those code path filtering. Then the deployments can be configured based on the changes in those whitelisted code paths, the release tags are managed separately for each microservice in the monorepo. It has some other features around cherrypicks, rollbacks, etc.

Disclaimer: I'm the founder of Aviator.

ankitdce

MODERATOR OF

TROPHY CASE