Argo Rollouts Best Practices

[ugrkm]

In the latest version of argo rollouts docs, there is a paragraph:

The recommended way to use Argo Rollouts is for brief deployments that take 15-20 minutes or maximum 1-2 hours. If you want to run new versions for days or weeks before deciding to promote, then Argo Rollouts is probably not the best solution for you.

which was added in #3484 cc @kostis-codefresh .
Why does it recommend that deployments should take maximum of 1-2 hours?
Would it cause a problem to have a rollout taking 3-5 days or a week?
What is the best solution for such use cases?

[kostis-codefresh]

Hello

Keeping parallel releases for long times, complicates the deployment process a lot and opens several questions where different people have different views on how Argo Rollouts should work.

You can find several discussions and issues where people don't agree on what should happen if you start a new deployment when an existing one is already in progress.

For example let's say that you are testing for a week version 1.3 as stable and 1.4 as preview.
Then somebody deploys 1.5

• Some people believe that the new state should be 1.3 stable and 1.5 as preview
• Some people believe that the new state should be 1.4 stable and 1.5 as preview

And then let's say that 1.5 has an issue. Some people believe that Argo rollouts should "rollback" to 1.3 while other people think it should rollback to 1.4

In a similar note, several discussions happen with resources and loads assigned to pods while you have long running versions.

All these problems are not present if you make the assumption that each release stays active only for 15 minutes and you always create one new version when the previous one has finished.

Could you explain a bit your use case? Why do you need one release for a week?

• If you really need a week to understand if something is successful then maybe you need to focus on your metrics first?
• If you want other people to test for one week, then just create a proper staging/pre-prod environment and deploy there with your normal deployment process. No need for the complexity of Argo Rollouts

[ugrkm]

In my use case, I am not planning to have multiple stable versions running at the same time. It probably won't take a week I just wanted to give an upper-bound. But it might take a couple days to verify the metrics and do some tests. Also, for example I want to run version 1.3 release with different configs. Like some of the pods would have feature A enabled and some disabled. That's why it might take longer. Also, enabling a feature should be independent from the release process in my case. I guess improving metrics might shorten that time. To your second point, I need to have production traffic to verify the release. Thanks

[kostis-codefresh]

But it might take a couple days to verify the metrics and do some tests

That is a big problem and should be solved regardless of Argo Rollouts. It doesn't make sense to wait that long. I think improving metrics should be your first priority. How do you solve this now? Do you have an actual human looking at metrics for a couple of days?

Also, enabling a feature should be independent from the release process in my case

Then you need a proper feature flag solution (e.g. launchdarkly, split etc). Argo Rollouts is not aware of feature flags and they are outside its scope.

To sum up, the best practices that I wrote assume that you already have some prerequisites in place. I hope it is clear now what is the context.

[ugrkm]

Yes, an actual human looks at some metrics. I aim to automate this by using the analysis feature of argo-rollouts. There is also some manual testing involved.
For the feature flags, we're looking into other solutions. We plan to use Argo Rollouts only for the release. But I expect it will go hand in hand with feature flag tool.
Yes, it is clear that there're some prerequisites and I got my answer that there aren't any hard requirements that conflict with my use case. These are just best practices. Thank you for explanations and your suggestions!