- 08 Mar 2022
- 3 Minutes to read
- Updated on 08 Mar 2022
- 3 Minutes to read
Deployment plans are the instructions that tell BuildMaster exactly how to deploy your build and perform any other needed tasks during a release.
They are written in language called OtterScript, and can be developed using the drag-and-drop editor. This saves you from having to learn the syntax before you can start building a plan. You can switch back-and-forth between visual and text modes to get a feel for the syntax and structure of the language pretty quickly, and master it in no time.
Text Mode (OtterScript)
Creating Deployment Plans
You can create a deployment plan at the application or global level. Global plans behave in exactly the same manner, except you may only reference global modules.
You may associate a deployment plan with an environment after you create it, which will allow you to restrict certain users from viewing its contents by defining an environment-scoped access control. There's no good reason to do this, as you shouldn't be putting sensitive information in your deployment plans… but sometimes it can't be helped.
Association with Pipelines
All deployment plans are run under the context of a build and a pipeline, except those defined as the target of a Repository Hook/Monitor plan. Visit the pipelines documentation for more information on how to configure pipeline stages and targets.
OtterScript is a Domain-Specific Language that was designed for high-level orchestration and automation across servers, and is used to represent build and deployment plans in BuildMaster.
To learn more, check out the OtterScript Guide in the Inedo Execution Engine documentation.
PowerShell and Shell Scripting
OtterScript was designed to seamlessly integrate with PowerShell and Bash/Sh, and can run inline script blocks, evaluate scripting expressions into variable values, and call externally -stored script files called assets.
Script assets can be added to BuildMaster at the application- or global-level. Once added, your scripts will appear in the statement list in the visual plan editor, and the parameters to those scripts will be parsed and displayed as textboxes when editing in visual mode.
Visit the shared PowerShell and Shell Scripting documentation for more information.
Modules are reusable plans that can be called from a deployment plan or other modules, as if it were an operation. Like deployment plans, modules can be created at the application- or global-level, and are edited using the visual plan editor.
To create or edit modules, go to the Modules tab on the plans listing page. Modules are available in the statements list in the visual plan editor.
Similar to operations, modules can have input- and output parameters. You can edit these by clicking on the Module Properties button in the Visual Plan Editor (when in visual mode), or by editing the OtterScript directly. These parameters are then accessible as variables within the module.
Modules are run within the scope of whatever block calls it, which means it will inherit all of that block's variables. As a result, you should generally avoid relying on externally-defined variables in modules.
Note: modules are called templates in BuildMaster v5.
Plan Version Control and Rollback
BuildMaster 5.8 and later maintains a history of edits and allows rollback to any plan version, similar to a "revert" in source control. Version history is maintained for both deployment plans and deployment modules.
On any plan's listing page, select the version number to display a list of all versions of the plan. From the Plan Version Listing page, there are options to compare any previous versions with the current. On the Plan Version Comparison page, any global plan or plan from any application visible to a user may be compared side-by-side.
To roll back to a previous version of a deployment plan, select the "edit" option of the desired version from the Plan Version Listing page, and then save the plan. This will create a new version of the plan with the same contents as the rollback target.