Octopus Deploy 3.3 has something for everyone (*):
- For Azure folks, Resource Manager integration and a new Resource Group Template step type.
- For those who live for the latest from Redmond, 3.3 brings a story for ASP.NET Core.
- And we haven't forgotten our base, with a set of improvements for executing scripts.
*Well...not quite everyone. Multi-Tenancy is not included. We address that below.
3.3 delivers the following new features:
- Script-steps can source the script from a package
- Script-steps can execute on the Octopus server without requiring a Tentacle
- Server-based steps (i.e. email, manual-intervention, and the new server-script steps) can be child steps
- Support for zip and tar packages
- OctoPack.js + gulp and grunt wrappers
- Azure Service Principal account type
- Azure Resource Group Template step type
- ASP.NET 5 (Sorry, ASP.NET Core) JSON configuration support
Upgrading to Octopus Deploy 3.3
Breaking changes for
Octopus.Client and the TeamCity plugin
You will need to upgrade
octo.exe and your TeamCity plugin with this release. You will also need to upgrade code that uses the
Octopus.Client if you are using the
For more information refer to our documentation on this breaking change.
Previously, for a stand-alone script step (i.e. a script not associated with a packaged application), the code was stored as part of the step configuration in Octopus Deploy. With 3.3 comes the ability for a script step to execute a script contained in a package.
This allows you to store your scripts in source-control, package them as part of your build process, and push them to Octopus Deploy.
When deploying applications, there are situations when you want to execute a script that doesn't need to be executed on a target machines. For example, executing some SQL against a database. There may also be scenarios where the script can't be executed on a target machine (due to network topology etc), and must be executed on the Octopus Server.
3.3 adds a new step type: Run a Script on the Octopus Server. This removes the need to install a Tentacle on the Octopus Server, which was previously the most common work-around.
If you have a step with children steps (often done to achieve rolling-deployments), you were previously unable to add server-based steps (e.g. Email, Manual-Intervention) as a child. With 3.3 you can now have a manual intervention per machine deployed to.
This feature combines nicely with Run a Script on the Octopus Server mentioned above. Perhaps you have a rolling-deployment of your web application, and have a PowerShell script step which removes the machine from the load-balancer before deploying to it. That PowerShell step can now be executed from the Octopus Server.
Octopus Deploy is no longer NuGet-only! We love NuGet at Octopus, but we understand there are times, particularly for those who live in a non .NET world, when creating a tar or zip file can be more convenient.
If you are using the built-in Octopus Package Repository, you can now use regular zip files, or tar files (+ GZip or BZip2). See our Supported Packages document for the details.
Check out our sample project.
This new account-type represents a Service Principal in Azure Active Directory. The motivation for this was integration with Azure Resource Manager API's, including the new step-type below.
This feature was indicated in our RFC last year. It allows declarative, immutable deployments to Azure.
Similar to the Script Step sourced from a package feature, the Azure Resource Group template can be entered as JSON source directly in the step, or can be contained in package. If it is entered as JSON source, we dynamically display fields for the parameters, which can of course be bound to Octopus Variables.
ASP.NET Core (formerly known as ASP.NET 5) is getting closer to a production release, and we know some customers are already using it, so we want to make sure it is supported.
There were previously some issues with packaging .nuspec files in a NuGet package. There were work-arounds, but it was a little painful. Now that we support alternative package types, that problem is entirely avoidable.
Also, JSON is the flavor du jour for configuration in ASP.NET Core, and we have added a new AppSettings JSON feature making it easy to write Octopus variables to your JSON configuration files.
We also now have some guidance on ASP.NET Core deployments in Octopus Deploy.
Many of you will have noticed an omission in the feature list above.
We promised multi-tenancy in 3.3. Multi-tenancy is not in 3.3. For this we apologize.
We intended for it to be included. We published an RFC on a potential implementation, and received much valuable feedback. The feedback caused us to reconsider our proposed design. At that point, we had to decide whether to hold back all the features above to wait for multi-tenancy, or ship 3.3 sans MT and take our time to ensure we get it right. Obviously we chose the second option. You will see a revised RFC very soon. Multi-tenancy is officially our #1 priority.