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.

Sign up for GitHub

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

docs: added clarifications for short releases #3753

Merged
merged 4 commits into from
Jul 31, 2024
+21 −1
Merged

docs: added clarifications for short releases #3753

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
40cc4dd
docs: added clarifications for short releases
kostis-codefresh Jul 29, 2024
70e30bf
Merge branch 'master' into doc-clarify
kostis-codefresh Jul 30, 2024
6a05b0a
docs: clarify current Argo Rollout behavior
kostis-codefresh Jul 30, 2024
f0ac4c8
docs: also clarify multiple versions
kostis-codefresh Jul 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/FAQ.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
# FAQ

Be sure to read the [Best practices page](../best-practices) as well.

## General

### Does Argo Rollouts depend on Argo CD or any other Argo project?
Expand Down
14 changes: 14 additions & 0 deletions docs/best-practices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,18 @@ You should *NOT* use Argo Rollouts for preview/ephemeral environments. For that

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.

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.

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

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

zachaller marked this conversation as resolved.
Show resolved Hide resolved
Also, if you want to run a wave of multiple versions at the same time (i.e. have 1.1 and 1.2 and 1.3 running at the same time), know that Argo Rollouts was not designed for this scenario.

A version that has just been promoted is assumed to be ready for production and has already passed all your tests (either manual or automated).
Expand All @@ -41,6 +53,8 @@ While Argo Rollouts supports manual promotions and other manual pauses, these ar

Ideally you should have proper metrics that tell you in 5-15 minutes if a deployment is successful or not. If you don't have those metrics, then you will miss a lot of value from Argo Rollouts.

If you are doing a deployment right now and then have an actual human looking at logs/metrics/traces for the next 2 hours, adopting Argo Rollouts is not going to help you a lot with automated deployments.

Get your [metrics](../features/analysis) in place first and test them with dry-runs before applying them to production deployments.


Expand Down
Loading