Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2019-06-04T10:30:14.053Z
Answers: You can also use helm or terraform so that you update image names/tags using environment variables.
Answers: SamwelOpiyo
Answers: CC BY-SA 4.0
Answers: 2018-09-02T15:20:53.340Z
Answers: 2018-09-02T15:20:53.340Z
Answers: SamwelOpiyo
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-05T22:53:01.820Z
Answers: 2018-10-05T22:53:01.820Z
Answers: Ricardo
Body: <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>
  
Tags: <kubernetes><deployment>
Title: Kubernetes Deployments & Rollbacks
UserDisplayName: Caledonia91
ThreadText: # 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.
  
  
  ---
  
  