Octopus Deploy 3.3 has something for everyone (*):
- For the non .NET crowd we have support for zip and tar packages, plus some JavaScript libraries to assist in creating and pushing packages.
- 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.
Features
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 octo.exe, 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 DeploymentProcess resource.
For more information refer to our documentation on this breaking change.
Script Steps sourced from a package
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.
Script Steps Executed on the Octopus Server
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.
Server-Based Steps as Children
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.
Support for zip and tar packages
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.
OctoPack.js
Continuing with the theme of making life a bit easier for non .NET folks, we have created some JavaScript tools to assist with pushing packages to Octopus Deploy. OctoPack.js brings some of the OctoPack functionality to Node.js. We've also created gulp and grunt wrappers, so pushing to Octopus Deploy from your JavaScript build-chain becomes much easier.
Check out our sample project.
Azure Service Principal Accounts
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.
Azure Resource Group Template Step
3.3 extends Octopus Deploy's Azure integration with a new Deploy an Azure Resource Group Step type allowing Resource Groups to be deployed via templates.
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 JSON Configuration
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.
Multi-Tenancy - A notable omission
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.
