Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orchestra Multiple Canary's #1700

Open
johnatowers opened this issue Aug 30, 2024 · 0 comments
Open

Orchestra Multiple Canary's #1700

johnatowers opened this issue Aug 30, 2024 · 0 comments

Comments

@johnatowers
Copy link

Describe the feature

My development team at work uses flux/flagger for all of our deployments. The biggest problem we have is the fact that our application is a monolithic monorepo. We deploy our backend and frontend (sometimes multiple front ends to one backend) at the same time, with multiple canary's and AC tests and whatnot.

However, we want to the frontends to continue in canary analysis if the backend has successfully deployed. If the backend fails, it should fail the dependent canary's.

Proposed solution

  • webhooks that only execute open canary success or canary failure
  • some sort of field within canary object that allows for them to communicate with each other?

Any alternatives you've considered?

  • manual gating. We do not want manual processes
  • separate charts into multiple charts, that then use api requests to GitHub to bump the frontend chart versions in order to trigger the deployment process (current implementation).

Are there any other solutions? I spent a considerable amount of time looking at the gates, and they are close to being a fit but not quite due to lack of support for webhooks that only execute on success or only on failure. Also they can be convoluted. We don't want to have our actests sending requests to the flagger deployment if we can avoid it.

Looking for other suggestions, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant