{
  "id": 3801290,
  "title": "The Rollback Worked. My Next Deploy Could Break It Again.",
  "url": "https://urgent.news/2026/08/27/the-rollback-worked-my-next-deploy-could-break-it-again",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-27T19:06:29.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/lbagga/the-rollback-worked-my-next-deploy-could-break-it-again-440p"
  },
  "original_language": "en",
  "account": "My application was restored to its previous state after a rollback. While this was a positive outcome, there was another issue at hand. The YAML file containing the application instructions still referenced Version 3, not Version 2. If I were to reapply the YAML file, it could unintentionally bring back the previous version. I corrected the YAML file manually and confirmed that both the file and the cluster were aligned. This resolved the immediate problem but also highlighted a weakness in my approach: recovery depended on my memory to update two different locations. This realization served as the foundation for a new project. The core issue was that Kubernetes had one answer to the question \"What should run now?\" while my YAML file had a different answer. The challenge was to establish a single reliable source for the chosen version. GitOps was the solution I aimed to implement. GitOps is designed to address this problem by providing a consistent record of the desired version. I contemplated who should be authorized to change the cluster. Initially, I thought the application pipeline, responsible for continuous integration (CI), would be the best candidate. CI continuously runs tests, builds the application, and can deploy changes. However, I decided that CI should not directly modify Kubernetes. Instead, CI would propose a release, which would then be reviewed and merged into Git. Git would store the final decision on which version should run in the environment. This approach separated the responsibilities: CI ensures the application can be built, Git records the approved version, and Argo CD, a Kubernetes tool, synchronizes the cluster with Git. To prevent any ambiguity in the approved version, I chose a release with a specific identity rather than a generic name like \"latest.\" Container images often use tags that can be altered, which would weaken Git as the authoritative record. Instead, I opted for an image digest, a unique fingerprint calculated from the image contents. This ensures that the selected release remains unaltered, even if the image contents change. I utilized Helm, a tool that allows the creation of reusable Kubernetes templates. These templates include various Kubernetes instructions, such as how to run the application, access it, check its health, and specify the image digest to use. Before integrating Argo CD, I wanted to thoroughly test Helm. I installed it, verified the application, performed upgrades, rollbacks, removal, and reinstallations in a controlled environment. This step ensured that the Kubernetes package and the automated delivery process worked correctly. To ensure a safe first deployment, I built a small Node.js service with four specific endpoints to test health, readiness, version, and metrics. The health and readiness checks were intentionally separate.",
  "summary": "My application was working again. That should have been the end of the problem. It was not. In [the first article in this series( https://blog.lalitbagga.com/posts/why-i-chose-k3s-debian-homelab ), I built an always on Kubernetes lab on my home server. I deployed a small application, changed it from Version 2 to Version 3, and then practised a rollback. Kubernetes restored Version 2 successfully.…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}