<p>I think it might be a good idea to update deployment.yaml for each version/release and commit to git so that later, any other person may follow through and even revert back to an earlier release/version.</p>

CC BY-SA 4.0
2019-06-04T10:30:14.053Z
You can also use helm or terraform so that you update image names/tags using environment variables.
SamwelOpiyo
CC BY-SA 4.0
2018-09-02T15:20:53.340Z
2018-09-02T15:20:53.340Z
SamwelOpiyo
<p>When we started to use Kubernetes at my current job we just re-applied the deployment manifest, updating the DATE on a annotation, this worked fine for some time, then we switched to use HELM <a href="https://helm.sh/" rel="nofollow noreferrer">https://helm.sh/</a></p>

<p>My recommendation is to switch to Helm since it manages deployments in a better way, even config maps are versioned between releases and also you can roll-back as you want.</p>

<p>Makes life easier when integration with CI/CD pipeline cause everything is parameterized/configurable.</p>

CC BY-SA 4.0
2018-10-05T22:53:01.820Z
2018-10-05T22:53:01.820Z
Ricardo
<p>At the moment I'm performing Kubernetes deployments by applying <code>deployment.yaml</code> then updating the container/pod image versions with <code>kubectl set-image</code> as outlined in the docs. I'm doing this using Jenkins.</p>

<p>If I understand correctly, each time I apply <code>kubectl set-image</code> it updates the deployment in situ creating a new ReplicaSet meaning that I don't need to create a new <code>deployment.yaml</code> for each version bump. </p>

<p>Is this best practice or should I be creating a new <code>deployment.yaml</code> every time we bump version?</p>

<p>My next question concerns rollbacks, if I run <code>kubectl rollout history deployment/name</code>, I see three revisions but no 'cause'. I think this is because I've not specified <code>--record</code> on the initial deployment, and does that record each time we do a <code>set-version</code> too?</p>

<kubernetes><deployment>
Kubernetes Deployments & Rollbacks
Caledonia91
# Kubernetes Deployments & Rollbacks

(Asked by: username_0 on 2018-08-23)

At the moment I'm performing Kubernetes deployments by applying `deployment.yaml` then updating the container/pod image versions with `kubectl set-image` as outlined in the docs. I'm doing this using Jenkins.

If I understand correctly, each time I apply `kubectl set-image` it updates the deployment in situ creating a new ReplicaSet meaning that I don't need to create a new `deployment.yaml` for each version bump.

Is this best practice or should I be creating a new `deployment.yaml` every time we bump version?

My next question concerns rollbacks, if I run `kubectl rollout history deployment/name`, I see three revisions but no 'cause'. I think this is because I've not specified `--record` on the initial deployment, and does that record each time we do a `set-version` too?

**Tags:** kubernetes, deployment


---

## 2 answers

### Answer by username_1 on 2018-09-02. Score: 2

I think it might be a good idea to update deployment.yaml for each version/release and commit to git so that later, any other person may follow through and even revert back to an earlier release/version.

> **Comments:**
> **username_1**: You can also use helm or terraform so that you update image names/tags using environment variables.  

---

### Answer by username_2 on 2018-10-05. Score: 0

When we started to use Kubernetes at my current job we just re-applied the deployment manifest, updating the DATE on a annotation, this worked fine for some time, then we switched to use HELM <https://helm.sh/>

My recommendation is to switch to Helm since it manages deployments in a better way, even config maps are versioned between releases and also you can roll-back as you want.

Makes life easier when integration with CI/CD pipeline cause everything is parameterized/configurable.


---

