Improve System Deployments through Scripting

Summary

Conversion / migration steps of system deployments can be performed faster and more accurately by capturing details in an executable script that reduces or removes the human element to the processing. Scripts can also check the target environment has the correct configuration before starting to avoid problems part-way through processing.

A script's investment return is magnified when a deployment is performed multiple times or across multiple environments (e.g. development, testing, and production). The script's consistency improves the final result by removing or reducing human error and delay.

What is a script?

When performing a deployment, there are often a set of mechanical, ordered actions that take the target environment from its initial state to some desired, changed final state. These actions can take an original empty environment to one that has a system deployed, or performs known and repeatable changes on an existing environment to update it.

A script's processing can include the capture or sourcing of variables and parameters that are then employed when doing the work. These variables may be entered by the invoking operator, or sourced from files in known locations or database entries.

Variables used in processing might indicate (say) whether to setup a new environment as a database or application server, or provide parameters that select the customers to be migrated. In each case, the invoked script includes processing for each circumstance that can be invoked, and switches its processing based on the variables it receives.

Why build a script?

A major reason to invest the time, and its close relation money, in a script is the belief that the benefits of the script will exceed the effort of the script's creation and maintenance. The benefits of building scripts includes:

Time Savings: Over the life of a system deployment, a configuration change may be performed multiple times. By allowing the change to be performed in an automated manner, the deployment changes or conversion can be performed faster than if actioned manually by a human operator working through a checklist.
Volume of processing: A script increases the work volume performed by operating without delay once preconditions are met. For example, a script performing a customer migration can execute within a smaller outage, or more customers can be converted per outage. System resources are better utilised by working under the script's control at the speed of the infrastructure's capacity rather than at the human operator's ability to react and type.
Repeatability/Accuracy: Since processing actions are listed explicitly in the script, consistent invocation can be relied upon each time the script is performed. Actions performed across multiple environments will be performed in a consistent manner.
Staff Independence: Performing actions correctly is decoupled from which staff invoke the script. Where a script is performed repeatedly across time or in multiple locations, accurate outcomes do not rely on the business' most knowledgeable staff for success. The knowledge of the best placed staff can be distilled into the script and performed by others without the experienced staff's direct involvement or supervision. Where used on a large deployment, the script's longevity may outlast the employment of the staff who constructed it.
Documented results: Scripts can be built to capture the results of processing always and not rely on the diligence of the invoking staff. This can be done by sending details to standard output where they can be read or captured, or the same and/or additional details may be logged to file for later examination.
Environmental Validation: Before a script performs any update actions, it can validate its environment to check if necessary files exist, software is at the necessary version level, and settings are what is expected/needed. Details can be captured and processing halted if discrepancies are noted before updates are performed. This allows environmental defects to be remedied before they adversely impact planned processing. Once defects are remedied, the script can be run again to confirm the changes made to solve environmental problems before the script performs its work. Scripts can also be configured with a 'check mode' that reports on the environment and performs no other action. Ideally this mode is included within the same execution script to avoid double (and possibly misaligned) script maintenance.
Documented assumptions: By implication, the script captures the environmental assumptions for installation and/or regular processing, and these can be referred to when later system defects occur. A script can form a baseline of what the environment's starting position was before later updates were made.
Scalability: Where appropriate, a script can be performed concurrently across multiple environments without proportionally increasing the staffing levels. The speed, accuracy and improved system utilisation this delivers increases the return on the script's investment.