Sunday, 8 October 2017

Re-release to an environment, don’t spin up a whole new deployment!

I know this happens on a regular basis – but it caught up my eye this morning as I am finishing up preparation for

Let’s say your Release fails:


What many do is to actually spin up a whole new instance of the Release itself. While this works ok, you are missing out on something important: traceability.

In a sea of releases, with microservices and multiple moving pieces, how would you be able to trace back what happened during that failed release?

Why don’t you actually try to re-deploy the same failed bits instead?


Doing this provides you all the details about the previous failures, and it is going to be much easier to recall in case you might need to refer to the scenario in the future.


Oh in case you were wondering… it was all about my lab’s DNS server, which cached the Kudu website of an App Service I was deploying as 404 Smile but it is Sunday after all…

No comments:

Post a Comment