Octopus 2020.2: Execution containers for workers
We’re pleased to ship Octopus 2020.2, our second release of the year. These are the helpful updates and benefits included in this release:
- Execution containers for workers (Early Access) let you execute deployment work in isolation without the need to manage dependencies and containers.
- Integrated change management with Jira Service Desk lets teams create change requests during their deployment automatically.
- Better run conditions adds deployment process improvements, including rolling deployment and machine level variable conditions.
- Fast variable lookups with our improved code editor unlocks the ability to quickly add Octopus variables into your custom scripts without touching the mouse.
This release is the second of six in 2020, and it includes six months of long term support. The following table shows our current releases with long term support.
|Release||Long term support|
Keep reading to learn more about the updates.
Execution containers for workers
Workers were introduced in Octopus 2018.7, and they help teams move deployment work off the Octopus Server and onto other machines running in worker pools. Common scenarios for workers include database deployments and cloud deployments, where you can create a pool of workers for that specific purpose. Worker pools can also be scoped to environments to suit your needs.
In this release, we added support to execute deployment work in isolated containers on workers, and we shipped a collection of official container images bootstrapped with standard deployment tooling.
Previously, you needed to ensure the machines in your worker pools (including the built-in worker pool) have the necessary tools required for your deployments, and you needed to maintain their OS and tool versions. This approach could also be problematic if different teams required different versions of specific tools that don’t install side by side. Also, Octopus bundled some tools, but it was still a challenge to keep them up to date.
Execution containers for workers resolves this issue and more.
- Isolated and fast execution of deployment work. Octopus is using Docker to execute your scripts or other deployment work in the context of a container. This method provides fast and efficient execution in complete isolation.
- Simplified dependency management with pre-built Octopus tooling container images. There is now far less friction required to ensure you’re using the right versions of the tooling that you need for your deployments.
Our pre-built images include cross-platform support for Windows 2019 and Ubuntu 18.04, and you can select the
latest image tag or a specific version based on major, minor, or specific patch versions. We are launching images with the following tools pre-installed.
- Powershell Core
- .NET Core SDK (3.1 LTS)
- Java SDK
- Azure CLI
- Az Powershell Core Modules
- AWS CLI
- Helm 3
- Azure Function Core Tools
- Google Cloud CLI
- ScriptCS (Window-only)
- F# (Windows-only)
It’s also possible to build container images with your team’s exact requirements. For example, you can build a customized image with a specific version of kubectl with the following command:
docker build -t my-company/worker-tools --build-arg Kubectl_Version=X.Y.Z MyDockerFile
Integrated change management with Jira Service Desk
With Octopus 2020.2, we shipped our initial support for integrated change management with Jira Service Desk Cloud. It is now possible to automatically create change requests during a deployment with our new Jira Service Desk Change Request step.
This integration works with our Octopus Deploy for Jira plugin and requires the ITSM early access. See Atlassian’s documentation for more information on configuring the Octopus Deploy integration within your ITSM project.
This feature is the first part of a more significant change management feature-set, so I recommend registering for updates on our public roadmap for more information about this feature.
Note: The Octopus Deploy plugin is only compatible with Jira Cloud and Jira Service Desk Cloud, as the APIs we depend on are only available in Jira Cloud. When those APIs become available in Jira Server, this extension will work there too.
Better run conditions
Run conditions allow you to customize each step in your deployment process to provide greater control over the step’s execution. This release adds support for rolling deployment and machine level run conditions.
Rolling deployment variable run conditions
It is now possible to add variable run conditions to child steps in rolling deployments. This update adds greater flexibility to rolling deployments and allows you to customize the deployment process based on your specific needs.
For example, if you are deploying a web service update to a web farm in a rolling deployment, you could sanity test the service after the update step and set the service status to an output variable. In a follow-up step, you can add it back to the web farm if the service status is positive with a variable run condition. Previously, this was not possible.
Machine-level variable run conditions
Another new addition to variable run conditions is support for machine-level variables. The rolling deployment example above highlights this improvement as well. In this example, the service status output variable is a machine-level variable as it is specific to a single machine. Machine level variables can be set and resolved in standard (linear) or rolling deployments.
Fast variable lookups in our updated code editor
We also added a handy shortcut to insert variables quickly without needing to click the variable lookup button.
Space to get a quick variable lookup menu with fuzzy search support. Select the appropriate variable using the arrow keys and then press
Enter. This simple update is quite useful once you get used to it.
Try it today!
Octopus 2020.1 introduced updated minimum requirements for running Octopus Server to Windows Server 2012 R2 and SQL Server 2017. This release is now enforcing the SQL Server minimum requirements.
Octopus Cloud users are already running this release, and self-hosted Octopus customers can download the latest release now.
As usual, the steps for upgrading Octopus Deploy apply. Please see the release notes for further information.
What’s coming in Octopus 2020.3?
Check out our public roadmap to see what’s coming next and register for updates. We’re already working on our Config as Code feature set, and it’s looking good.
Octopus 2020.2 is here, and it brings some nice improvements. Execution containers for workers and integrated change management with Jira Service Desk are the first steps of these feature sets that simplify deployments and release management.
Feel free to leave us a comment, and let us know what you think! Happy deployments!