In a running deployment if i have to do multiple changes in one go , thereafter . . .

R:
in a running deployment if i have to do multiple changes in one go , thereafter , i have to undo those changes, or go back to previous revision. What is the best way?

Fernando Jimenez:
Are all the changes part of the same revision? Could you say what those changes might be?

R:
i had to change the image, maxsurge and max availablity

Fernando Jimenez:
Make all of them as part of the same revision. One time editing the deployment.

R:
i was not able to find that command

R:
k edit deploy xyz

Fernando Jimenez:
Yes, you can edit a deployment like that or you can

kubectl get deploy xyz -o yaml > deployment.yaml

then open the file and make the changes, following with

kubectl apply -f deployment.yaml

R:
yes, i did the same. but when i did undo, it says nothing to undo

R:
error: no rollout history found for deployment “nginx”

Fernando Jimenez:

kubectl create deploy web --image=nginx:1.16

kubectl rollout history deploy web
deployment.apps/web
REVISION  CHANGE-CAUSE
1         <none>

Changed it to nginx:1.17

kubectl edit deploy web

kubectl rollout history deploy web
deployment.apps/web
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

srikanth arani:
@Fernando Jimenez should he be using --record flag along with the deployment command?

Fernando Jimenez:
–record will place the command utilized, in this case kubectl edit deploy web into an annotation in the deployment object. I do not know if that’s what is wanted but it does not change the result of the rollout history.

R:
i have another option to keep two manifest yaml files created one with original configuration and the other with changed configuration. it will then solve the purpose. However, i am not sure is there any other approach to fulfil this demand or its the only way of keeping two files to revert back to original state.

Fernando Jimenez:
A rollout is only for changes to the containters template, and it is implemented via the replicaset (first spec). However, I am started to think you are talking about the whole deployment object. In that case, you have to keep a version system on the yaml file.

R:
ok thanks @Fernando Jimenez