Advanced Options

OttoDeploy exposes a set of Advanced options for deployments which can be used for more advanced use cases. When you turn on the Advanced options you will see a set of new options, including:

• Add sub-deployment
• Use a different source for each deployment
• Abort remaining sub-deployments if one fails
• Build settings for Just In Time builds
• Using a build as a source for a deployment
• Concurrency settings for sub-deployments
• Selecting a specific sub-deployment or set of files to run
• Slack notifications
• Keeping files closed at the end of a sub-deployment
• Waiting to close files after the files are fetched for a sub-deployment

Many of the advanced options are contained on their own tab in each sub-deployment:

The Post-Deployment Script setup also moves into this tab when advanced options are turned on.

If you would like to turn the advanced options on for new deployments by default, you can change that in the OttoDeploy settings.

Turn on Advanced Deployments

If you need the Advanced Options you can turn them on and off by clicking on the three dots in the top right corner of the deployment view.

Selecting a Build

Using the advanced options allows you to specify a source build to deploy to your destination. The builds will be fetched from your source server to select, and you can choose to deploy a specific build or to build the latest version of your source file using a "Just in Time" build. By default, we will run a Just in time build if you do not select a specific build. Just in Time builds are also the default for deployments not using advanced options.

For more information on builds, see our Builds documentation.

Just In Time Build Options

For Just In Time builds in advanced deployments you can set the build options for the just in time build. See the compression and memory settings for more information.

Abort Remaining on Failure

The Abort Remaining on Failure option allows you to prevent running subsequent sub-deployments if one fails. This may be useful if you are running a series of sub-deployments that depend on the preceding sub-deployment to succeed. Setting the Abort Remaining on Failure option will prevent the subsequent sub-deployments from running if a preceding sub-deployment fails. The failing sub-deployment will still be fully reverted and the deployment will be marked as failed.

For example, if you have a deployment with three sub-deployments and the second sub-deployment fails, the third sub-deployment will not run. The first sub-deployment will not be reverted, as it was fully successful.

If you do not want to abort the remaining sub-deployments if one fails, turn off the Abort Remaining on Failure option. This would be the case if you were deploying a single file to three different files on the destination server and they did not depend on one another. This is the default setting.

Sub-Deployments

Sub-Deployments are described in detail in the Sub-Deployments section of the documentation.

Each sub-deployment gets the option to use an alternate source (including a different build!) and to run seperate post-deployment scripts or close specific files while running. Sub-deployments can be easily re-ordered using the arrow buttons in the top-right corner of the sub-deployment. There is also the option to duplication sub-deployments and delete specific sub-deployments in the top-right corner of each sub-deployment.

Each sub-deployment requires a name and source files. The name is used to identify that sub-deployment in the OttoFMS console.

Use Alternate Source

Each sub-deployment can use an alternate source to fetch its source files. The source can be a different build on the same source server, a different server, or even an external url. If you do not turn on the "Use Anternate Source" toggle, the sub-deployment will use the default source that you selected at the top of your deployment.

Running part of a Deployment

When advanced options are turned on a checkbox will appear at the top of each sub-deployment and on each file in a sub-deployment. Unchecking these checkboxes will prevent that sub-deployment or file from being added to the deployment that gets sent to OttoFMS. This can be useful if you want to run a specific part of a deployment or if you want to run a specific file in a sub-deployment. When deselecting a sub-deployment, the sub-deployment will collapse so that you can focus on the sub-deployments that are selected.

You can also choose to only run one sub-deployment using the button in the top-right corner of each sub-deployment. This will deselect all other sub-deployments and only run the selected sub-deployment.

Close Files After Build

The Close Files After Build option allows you to close the files after they are fetched from the source server. This can be useful if you want to keep the files open on the source server for longer while the deployment is running. By default, this option is turned off.

Slack Notifications

You can setup Slack channels to receive notifications when a deployment is started, completed, or fails. Slack channels can be set in each sub-deployment and in the OttoDeploy settings. Deleting a channel url from the settings will not affect existing deployment, but will prevent new deployments from selecting that url.

Keep Files Closed After Deployment

The Keep Files Closed After Deployment option allows you to keep the files closed after the deployment is completed. This can be useful if you want to keep the files closed on the destination server while you undertake some manual post-deployment steps. By default, this option is turned off.

Concurrency

The sub-deployment level concurrency setting allows fine-grained control over how many file operations run at once. This can be useful if deploying a large number of files to a server with a large number of resource. By default this is set to 1, meaning that only one file operation will run at a time.