Resilient Scripting is scripting that can be rerun... safely


Making a script that is resilient can mean many different things to different people, IMHO an important one is to be able to re-run a script "safely". By safely I mean to minimize side effects and to prevent negative consequences.

To illustrate let's say we have an install process and we need to log details about what happens when we run the install.

To keep this simple let's just focus on the logging requirement.

We want a log file that we can look at when an install happens. So a simple approach would be as follows.

Set-Content log.txt "Information about Install"

Nice and simple, we have satisfied the requirement. But let's see if we can make this one liner more resilient.

$logFileTime = Get-Date yyMMddhhmmss
$logFileName = $logFileTime + "_log.txt"
Set-Content $logFileName "Information About Install"

Now even if we run this install multiple times we will have a script for each instance of the install even when it happens on the same day during the same minute. Further more an interesting side effect of making a script more resilient is that we know can see how many times this install is run because we have a file for each instal attempt. So the benefits of making it more resilient compound.

I hope this simple example helps you dear reader see how taking a second pass at making a script more resilient, even a one liner can benefit from a second pass. 


Popular posts from this blog

.NET MSTest and DeploymentItem Attribute

Using telnet to troubleshoot connectivity.... and watch Star Wars

Things I need to remember... IIS Express ports for HTTPS and Configure WCF Rest endpoints for HTTPS