Configuration Files, Custom Scripts, SQL Databases

We hope you are enjoying learning about Deployment. So far, you have learned about the deployment process and steps of deployment. In this step, we will cover three things: Configuration Files, Custom Scripts and SQL Databases.

In the first of these, Configuration Files, you will learn how one of the practices of continuous delivery is to deploy the same package on all environments and apply a different configuration in various environments.

Next, you will explore many out of box actions which Octopus supports and, finally, you will learn the requirements when deploying to SQL databases. We hope you gain a lot from this learning step.

Configuration Files

One of the practices of continuous delivery is to deploy the same package on all environments and apply a different configuration in various environments.

Octopus follows this principle, and several of the built-in steps have support for parameterising configuration files.

All steps that support NuGet packages have a way to parameterise configuration files.

Some of the step templates that have support for configuration files feature:

• Deploy to IIS
• Deploy a Windows Service
• Deploy a package
• Deploy an Azure Cloud Service
• Deploy an Azure Web App
• Deploy a Service Fabric App

The feature(s) can be enabled or disabled on the Configure feature link on the step configuration:

Some features are platform-specific (such as Configuration transforms) and some are more generic. This might be JSON configuration files or Custom deployment scripts.

The features are configured on the step parameters:

The features set is not fixed; it depends on the step type. Some steps might have additional features that can be enabled, while others may have fewer. Features also support things that are not related to configuration.

Configuration is often, if not always, combined with Octopus Deploy Variables to support different configurations per environment/role/targets/steps/tenant.

Octopus Deploy supports several mechanisms out of the box. If you are deploying to a platform that has a different configuration mechanism, you can either look to see if there is already a community step template or use a custom script.

Learn more about how to configure Configuration Files.

Custom Scripts

Octopus supports many actions out of the box, ranging from parameterising configuration files, creating IIS sites, deploying to an Azure Web App, creating a Docker, to sending an email.

Sometimes neither the out-of-the-box actions nor the community-created ones are enough. In this case, it is possible to run custom scripts to perform any action that can be automated.

Scripts are written in Windows PowerShell, C#, Bash, or F#. (Support for other languages is scheduled.)

You can store the scripts inline in the step configuration [1] or a package [2] for reuse:

Learn more about Custom Scripts.

SQL Databases

When you are deploying to SQL databases, you either use a model-driven approach or a change-driven approach (either with a tool or by creating SQL scripts manually). Octopus Deploy does not have any action out of the box to support it.

There are many third-party tools to support database change management, from both commercial and open sources, including:

• Microsoft SQL Server Data Tools projects
• Red Gate’s ReadyRoll
• Flyway
• DbUp
• Liquibase

When you are deploying to SQL databases, you either use a model-driven approach or a change-driven approach (either with a tool or by creating SQL scripts manually). Octopus Deploy does not have any action out of the box to support it.

There are many third-party tools to support database change management, from both commercial and open sources, including:

Learn more about deploying to SQL databases. The documentation contains a detailed explanation of how to use third-party tools to deploy database changes.

Now it’s time to complete the last step of Week 4.