It's best to fail as close to the point of originating a change because it's much easier and cheaper to fix.
When people talk about 'failing early' it's often as an approach to testing code - most noticeably through TDD/unit testing.
However, you can really apply the idea to most things.
I was thinking today about deployments.
Wouldn't it be good if you knew that your deployment was going to be work before you even started it? How many times have you had issues because there wasn't enough disk space or you couldn't reach all the servers you needed to?
What we are going to do is a series of pre-deployment checks. I want to fail before a deployment not mid way through.
I think that's a pretty good practise. Automatically test everything before you start with a set of environment readiness scripts. Is the environment in a state that you expect? Does it have the version and configuration that you expect?
If it doesn't fail the deployment and investigate. It will save you all kinds of headaches.
It's also a good idea to kickoff a load of automated tests after a deployment. I'd rather know if there was an issue BEFORE the business/test team get their little mitts on it...
Failing is good. You learn, you fix.
No comments:
Post a Comment