In my experience there are two IT infrastructure script templates that will perform the following actions against any number of IT Objects :
- Collect Template: Read and Log Configuration
- Change Template: Read and Change Configuration
IT Objects are the fundamental elements or objects of all IT infrastructure:
- Servers (Physical or Virtual / On Premises or In Cloud)
- Storage Solutions (On premises or In Cloud)
- Workstations ( local or remote)
- Network Devices ( local or remote)
Focusing efforts on defining the organizational requirements for each of these types of scripts will greatly reduce the amount of time it takes to develop and deploy new scripts. If there is a standard, approved template for each script type the only changes needed are for the specific application. The templates can grow over time and become more specialized to further reduce development and testing time.
This may sound like common sense to some but unfortunately it is usually not done. In most IT environments, especially large Microsoft Windows focused ones, scripting is not seen as a primary method for completing infrastructure projects unless there is no other possible option. The status quo is typically repetitive manual effort or trying to utilize highly complicated IT infrastructure "support" tools that rarely fully implemented, supported or located in an IT silo that discourages use.This often leaves scripting to be championed by a small subset of the workforce with little support from management. Usually each IT pro doing scripting does it differently then the others.
Working from a shared code base is commonly done in traditional software development because the complexity of the code requires it and its more efficient use of labor. For example it would not make sense to let each software developer each create their own approach to error checking or logging when they are supposed to making a single application. This is why software development houses have design standards and style guides that their developers must follow.
It may sound unromantic to some who see coding style as an extension of artistic style but to those I say take a painting class. IT infrastructure coding is not the best place for individual expression or doing risky things. The unfortunate truth is no one really cares how beautiful or inspired or complex your code is. At the end of the day results matter more than style and that is especially true when management are weighing the value of an approach to accomplishing work.
Typically the most time consuming part of script development is developing the wrappers for the commands you want to run. This is especially true if the people doing the scripting are relatively new to the process. The wrapper is all the code around the code that is doing the actual change or reading the actual information. The most critical wrapper features are:
- Target looping code = This is the list of IT objects the information is being read from or the the change is being made to. The script needs a way get this list and then loop through it. The list can be created dynamically or statically depending on need. The script template should have an approved approach for each.
- Error checking logic and logging of results = Unfortunately this is typically left out of most scripts. There should be exception handling around any command that is dependent on accessing some kind of IT object to continue. The template should be able to handle the IT object not being present or accessible. The result, error or success, should be logged for review later. This way the result of every command run against the environment is known. This kind of accountability is critical for gaining management support for scripting efforts.
- Script Security = This is often even more overlooked then error checking and logging. Most often this handled by having an approved method of handling the credentials that a script will run under. Script signing is also important as it ensures that a script has not been changed from its released version. Part of the template approach is also defining the release and execution process for a script to ensure security concerns are addressed from the start.
In the vast majority of cases this wrapper code will only need to change slightly and can be reused from one project to the next. Utilizing this kind of modular approach to your infrastructure projects, regardless of scripting language can greatly reduce the time and risk involved.
In future articles I will explain how to foster a scripting culture in your IT environment and provide more implementation details on utilizing PowerShell to create these script templates.