The script management comprises different functional areas:

Different tools can be used to create scripts. So the PowerShell ISE with the ScriptRunner ISE app is very well suited for creating new and changing existing scripts. But also other editors like Visual Studio (Core) are suitable to develop PowerShell scripts.

The ScriptRunner ISE app in conjunction with the ScriptRunner Admin app supports viewing, sharing, modifying, checking in and checking out scripts. A version history is created and a version copy is created in the central staging directory each time a change is made, provided the archiving function has been activated using ScriptRunnerSettings cmdlets.

For version control other systems like Git, SVN, TFS and others can be used with ScriptRunner. In this case, ScriptRunner can be configured using ScriptRunnerSettings cmdlets so that the script directory from the repository can be set to a checked out Git, SVN, TFS, etc. directory is created.
It is important that the checked out directory is located on the ScriptRunner Service Host. The Script Library Connector in the Admin displays the current configuration.

ScriptRunner automatically recognizes the scripts in this directory and integrates them into ScriptRunner including the generated metadata. Among other things, the description for the script is automatically read from the synopsis or the description in the script header and is displayed in both the ScriptRunner Admin App and the Delegate App and is also used in actions and reports.

Updating the Git, SVN, TFS etc. directory can now be done by ScriptRunner itself via a corresponding script using Scheduled Action. Changes, new scripts etc. are automatically detected and it is checked whether the scripts still match the assigned actions, contain errors or can still be used.

ScriptRunner has also been extended by a function to import already existing scripts. In this context, the example scripts have been removed from the installation routine and are included separately in the setup package. So every customer can access examples and import them into his ScriptRunner environment as needed. The imported scripts are stored in the repository under the _UPLOAD_ directory. Tags can already be assigned to the script during import.

The tagging of scripts was further extended and system tags were added. In the basic function, subdirectories of the Script Library directory are automatically mapped into tags by ScriptRunner. If a script is moved between subdirectories, its base tags also change. This has to be considered especially against the background of the integration of Git, SVN, TFS and other directories.

The automatically generated tags on scripts can be removed, changed or supplemented, since they are metadata of the scripts. The original directory structure is retained.

Besides these tags there are some system tags in ScriptRunner. For example, a script imported with the Admin App is marked with the _UPLOAD_ tag to better identify and search for it. This system tag can be removed later.

If a script in the ScriptRunner Admin app is released for editing with the ISE app, it gets the system tag _DEV_ and controls the check-out and check-in process. If the release is then withdrawn again, the system tag is automatically removed.

Testing modified scripts is an important part of quality assurance and the process chain for scripts. ScriptRunner supports testing with two very different functions: Staging and Pester.

During staging, a modified PowerShell script that has NOT yet been checked in is handled separately in the associated action. With the Admin App the changed script can be executed on a test system, while the same action e.g. for Delegate App users is executed with the previous script on the previous target system. Thus ScriptRunner enables a DevOp to make very agile changes to scripts and to test them.

Pester is a unit test framework to test self written Powershell functions. Besides the necessary PowerShell module “Pester” the DevOp writes corresponding test scripts by calling its own function with the Pester module. The corresponding test scripts are organized in ScriptRunner under the sublibrary Pester.

More about Pester also here :https://www.powershellmagazine.com/2014/03/12/get-started-with-pester-powershell-unit-testing-framework/

Scripts are ultimately used by ScriptRunner in actions. An action is an execution policy that specifies which script can be executed on which system with which administrative account, which parameters are entered and which are preset, who is authorized to start the action and how the start is performed (manually, delegated, scheduled, event triggered).

Script management in ScriptRunner supports the creation and compliance of execution policies with various functions. The continuous monitoring of the Script Library directories ensures that desired or unwanted changes are noticed. New scripts that have been copied directly into the directory, for example, are automatically recognized. Script parsing creates metadata, which is then checked for changes, e.g. if parameter definitions of the scripts have been changed and no longer match the already configured action/policy. The corresponding action is treated as incorrect and is no longer executed. The same applies to scripts that have been erroneously or intentionally deleted from the Script Library directory.