[FR-126] Rollback

[eniko-dif]

What was changed

Add a separate rollback config to the deployment specification that can be used to have different rollback behavior from the rollout one. It supports AllAtOnce or Progressive and does not have a gate. Uses the LastCurrentTime of a deployment to decide if the target version supposed to be rolled out or rolled back.

Why?

Open feature issue: #126

Checklist

1. Closes [Feature Request] Rollback mode #126

2. How was this tested:

Unit and integration tests (ongoing actual test with local setup).

3. Any docs updates needed?

Yes, but needs to be decided where.

[CLAassistant]

All committers have signed the CLA.

[jlegrone]

I think if we have a progressive rollout mode, we should also require that there be at least 1 step defined. It could be reasonable to assume that choosing the progressive rollout mode without also adding steps would reuse the existing steps from the rollout config. Without steps, progressive and all at once modes would behave the same way, right?

[eniko-dif]

The validation is the same as for rollout, so there cannot be a no-step progressive strategy (done in the webhook). "It could be reasonable to assume that choosing the progressive rollout mode without also adding steps would reuse the existing steps from the rollout config." I would not assume this, it seems like a nasty side-effect, but if you think it's a good way forward, I can implement it.

[jlegrone]

This is a change in behavior that should be called out in release notes.

Is there a way to disable rollbacks and keep the existing behavior of treating every version change as a new rollout? This should be documented as well.

[eniko-dif]

Now it's possible to disable the rollback by setting the max version age to 0. I've also updated the docs.