We are proud to announce the release of Octopus Deploy 3.4 Beta 2. We consider this release to be feature complete apart from small enhancements and bug fixes. There is still time to get involved in the Early Access Program (EAP) for Octopus Deploy 3.4 and let us know what you think!
Follow our mini-blog series on all the great features in Octopus 3.4!
- What's new in Octopus Deploy 3.4 Beta 2?
- Breaking changes and deprecation notices
- What is still left to be done before we ship Octopus 3.4?
- Getting started with Octopus Deploy Beta 2
In this release we have been building on the foundation of 3.4 Beta 1, with improvements to existing features, and have finished upgrading to NuGet 3, adding support for SemVer 2 and F# custom scripts. We have also finished work on
octo.exe and the TeamCity and VSTS extensions so you can fully integrate 3.4 Beta 2 into your existing build pipeline, including all of the new Octopus 3.4 features.
You can see which bugs have been fixed in 3.4 Beta 2 in our GitHub repository, and feel free to take a look at the feedback everyone has been posting! Also, check out our Octopus 3.4 blog series for a deeper look into the new features and insight into the decisions that went into building the release.
Apart from small enhancements and bug fixes, we have completed the work for multi-tenant deployments for Octopus Deploy 3.4.0. Rest assured, we will continue to work on improvements over the coming weeks and months.
Notable changes and improvements:
- You can now search for tenants by name and tags
- The global dashboard has been updated to correct some mistakes we made when displaying tenanted deployments for your projects/environments
- The multi-tenant project overview has been improved, including:
- improved filtering
- the ability to group by tag set
- the ability to deploy to groups of tenants, or even all the tenants in a particular environment
- it is now easier to understand which tenants are connected to which environments
- We have changed the way we calculate which deployment targets and accounts are included in deployments for tenants, which will make it easier to design tenanted and un-tenanted hosting scenarios:
- Tenanted deployments use tenanted deployment targets and accounts (with a tenant filter of some kind).
- Un-tenanted deployments use un-tenanted deployment targets and accounts (without any kind of tenant filter).
- We have also updated all of the tools and integrations to work with tenants - take a look and see what you can do
The best place to get started with multi-tenant deployments is our guide.
Apart from small enhancements and bug fixes, we have completed work for elastic and transient environments support for Octopus 3.4.0.
Notable changes and improvements:
- We have fixed a bug where project triggers were unexpectedly firing after a manual deployment
- We have made it possible to use auto-deployments for brand new environments without any existing deployments, which enables you to create test environments on-the-fly. This is really useful for working with immutable infrastructure (thinking of servers as "cattle not pets"), and testing feature branches. You can read more about this in our guide on immutable infrastructure.
- We have also updated all of the tools and integrations to work with elastic and transient environments - take a look and see what you can do
The best place to get started with elastic and transient environments support is our guide.
You can now write custom scripts in F# (
*.fsx) in addition to our other supported scripting languages. See this GitHub Issue and take a look at some examples of what you can do with F# scripting as part of your deployments.
We have replaced our dependencies on NuGet.Core by upgrading to NuGet 3 across the board, which means we have been able to close some long-term bugs, and support external NuGet v3 feeds! See this GitHub Issue for more information.
- Automate Tentacle registration using
octo.exeand the build server extensions to perform tenanted deployments
- Automate anything and everything in Octopus 3.4 using the
We will be updating the documentation over the next few weeks. In the meantime you can use the help provided by the tools, or reach out to us for support or to offer feedback.
In Beta 2, we have moved the proxy configuration for Listening Tentacles into the Environment area. In Beta 1 you were required to grant System Administrator permissions to users so they could manage Tentacle proxy configuration. Now users can manage Tentacle proxy configuration after being granted the usual
In a future release of Octopus Deploy we will cease support for the Azure Cloud Service and Azure Web App deployment targets.
Changes to health check results
We have introduced a new property
MachineResource.HealthStatus for elastic and transient environments which can be either
Unavailable. You can continue to use the existing
MachineResource.Status which can be either
Offline in Octopus 3.4, but we have marked the
Status property as
Obsolete and will be removing it in a future release.
Registering a brand new Tentacle with Octopus 3.4 will fail if you are using an older version of Tentacle. This happens because old Tentacle doesn't understand Cloud Regions and couldn't deserialize them. We have patched Tentacle to be more resilient to these kinds of changes in the future.
Note: This issue only affects registering new Tentacles with your Octopus Server. Existing Tentacles will continue to work as per normal.
- Registering 3.0.x Tentacles (used for older .NET 4.0-only servers): please download Tentacle 3.0.26 which has been patched to work with Octopus 3.4.
- Registering a newer version of Tentacle: please start using the a 3.4.x Tentacle release (we recommend the latest).
Changes to built-in repository error codes
When you push a duplicate package to the built-in package repository we will now respond with HTTP status code
409 Conflict instead of
400 Bad Request. Clients like
nuget.exe would only show the HTTP status code, dropping the reason Octopus returned explaining why it was a bad request. Using
409 Conflict for this situation should make it easier to diagnose. Refer to this GitHub Issue for more information.
Apart from working with our fantastic Octopus community on feedback, we still need to:
- Keep fleshing out our guides to help you make the most of these new features.
- Provide guidance for migrating tenants into Octopus 3.4 using the API.
- Further improve performance for really big installations with hundreds of tenants, environments and deployment targets.
Try it out on our 3.4 Beta 2 demo server using the guest account or get in touch with with our support team for elevated credentials.
Have an Azure subscription? You can spin up an entire Octopus setup using your own Azure subscription with our newly published template in the Azure Marketplace. This will install the latest stable version of Octopus Server on the VM, but you can use remote desktop to upgrade the Octopus Server to the EAP version. Finally you can easily delete the entire Resource Group when you're done!
Want to install it yourself?
Octopus Deploy comes with a 45-day Enterprise trial license. Download the Octopus 3.4 Beta 2 release taking a look through the release notes. We will support upgrades from these Beta releases to the full release of Octopus 3.4, but we do not support downgrades to a previous version of Octopus. If you want to upgrade an existing Octopus server, don't forget to take and test a backup of your database. Otherwise we recommend installing on a trial server.
Please post any feedback and join the conversation in our discussion forum.
Go ahead, get involved and help us build the best Octopus Deploy yet. Happy Deployments!