Hedgehog Documentation

Execution Types

  • Last Modified: 2019-07-18

There are several types of executions.

Pipeline Stage Execution

This execution is initiated through Pipeline deployments (i.e. not quick deploy), and deploys a specified Deployment Set to the specified Stage in its pipeline. It will also dispatch additional Pipeline Targeted Deployment Executions.

A pipeline stage is comprised of several elements, including pre-deployment steps, deployment targets, and post-deployment steps. Because pre- and post-deployment steps are effectively OtterScript operations (except for Execute OtterScript Plan, which is a plan), sets of pre- or post-deployment steps are converted into a single OtterScript plan. This OtterScript plan runs in the localhost server context by default, but other servers may be targeted using the "for server..." OtterScript notation, as long as those servers are not restricted by environment.

After validating that the package set can be deployed to the specified stage and the pre- and post-deployment plans are valid, the pre-deployment plan is run. Each target is then evaluated, and a Pipeline Targeted Execution is dispatched for that target. Once all targets have completed, the post-deployment plan is run.

Infrastructure Import Execution

This execution is dispatched either manually (from the web UI), or from the Infrastructure Sync Task Runner when the infrastructure has changed.

The manually dispatched execution has the following options:

  • Infrastructure JSON: a document describing servers, roles, environments, and variables on each
  • Flags: various Boolean options
    • Import Variables: variables described will be imported/replaced
    • Mirror: infrastructure not in the JSON document will be deleted
    • Dry Run: no actual changes will be made, only logged

When triggered manually, the user will provide the JSON and checkboxes for each of the flags.

When triggered from the task runner, the JSON will be whatever was returned from the other instance's infrastructure. In addition, variables will be imported, the infrastructure will be mirrored, and it will only be a dry run if configured globally to be a dry run.

Automatic Approval Gate Execution

TBD. This may or may not be needed, because the task runner probably won't fail; it would be dispatched from the web front for diagnostic purposes, similar to how issue import works in buildmaster.

Deployment Execution Types

A deployment execution runs a specified deployment plan against optional Server Targeting, while providing additional context (such as runtime variables and information about the project, release, package, etc).

There are two types of deployment executions: Package Deployment and Pipeline Deployment. Both types use Server Targeting.

Package Deployment Execution

This is a Deployment Execution that is initiated through the Quick Deploy workflow. A Server Target is always specified, and the deployment plan is either stored within Hedgehog or the package (install.otter).

Once loaded and compiled, the actual plan is wrapped in a Set Context Statement (with a ContextType of package, and ContextValue of the package name). The plan is then wrapped using the Server Targeting described below.

Pipeline Targeted Execution

A Pipeline Targeted Execution is dispatched by a Pipeline Stage Execution, and allows for deploying multiple packages in a package set.

Each package in the set is wrapped in a Set Context Statement (with a ContextType of package, and ContextValue of the package name), and that plan is then wrapped using the Server Targeting described below.

Server Targeting

If Server Targeting is also specified, then the plan will be wrapped as follows before execution.

Direct Targeting

A single Context Iteration Statement will be created with the Source set to a literal expression of the server names (e.g. @(Server1, Server2, Server3). The Body contain an Execution Directive Statement with an Asynchronous flag, and the Body of that will contain the actual plan.

Roles + Environment Targeting

For every role targeted, a Set Context Statement (with a ContextType of role, and ContextValue of the role name) will be created. The Body of those statements will be comprised of a single Context Iteration Statement with the Source set to a literal expression of the servers in that role and environment. The Body contains an Execution Directive Statement with an Asynchronous flag, and the Body of that will contain the actual plan.

If no servers were in any of the role iterations, then a Log-Warning statement will be appended to the wrapped plan, as the actual plan will not execute.

Pre-execution Failure

This execution invokes the OtterScript runtime to execute either the specified plan directly, or a wrapped version of the plan.

If an error condition occurs before the runtime is invoked, such as a complication error or a pipeline resolution error, the error message will be written to logs, the Execution Status will be set to Error, and the Run State will be set to Completed.

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit ce197caa on master