- Makes a reuse of the script easy. Just make another configuration file, and you have a reuse.
- Makes test and deployment possible. With a configuration file your script can be executed in all environments with the right values.
. ".\myScript.taskOne.config.ps1"
When I use the structure for a SQL Agent job with several steps, like import data from various sources, I like the naming "{task}.{job step}.config.ps1".
Each value in the configuration file is defined as a normal PowerShell variable. If you want to tighten your solution, you can define context or type.
[string]$script:SourceServer = 'SANDY.sqladmin.lan'
The configuration file can be tested in the script file on each run by checking the parameter and their value.
One thing I almost always define i the configuration file is the logfile name for the current script execution. Usually with a timestamp in the name.
The solution I have used in production, and it works fine. The simplicity makes it easy to use and maintain.
I tried some XML formatted configuration files, like in Visual Studio projects, but I found them too complicated to use in a script as I had to parse the XML file to get the values.
Also some old-style configuration files, also called initialization files, use to define sections with [] and values assigned in the sections. Again I found them too complicated to use. Usually the initialization file is accessed with regular expressions, which I normally find to be a rather powerful tool, but when I can do a thing more simple, I do that - Occam's razor...
No comments:
Post a Comment