Cowboy in the desert.

Octopus Deploy 3.4 EAP - Beta 1

Michael Noonan

Octopus Deploy 3.4 has shipped! Read the blog post and download it today!

We are proud to announce the release of Beta 1 as part of the Early Access Program (EAP) for Octopus Deploy 3.4! There is still time to get involved and let us know what you think!

What is available in Octopus Deploy 3.4 Beta 1?

In this release we have completed the core deployment features we are planning to ship, writing guides to help you get started, and we have been testing all of this internally for a few weeks.

Multi-tenant deployments

Multi-tenant deployments are essentially completed, apart from some notable omissions, and are ready for you to start testing in earnest.

The best place to get started with multi-tenant deployments is our guide.

Support for elastic and transient environments

We have completed the feature set for elastic and transient environments, including Machine Policies, new project configuration options, Project Triggers (auto-deploy), and a new Health Check step you can add to your deployment processes.

You can combine these features enable scenarios like:

  • auto-scaling web servers based on demand
  • updating applications on workstations/laptops that are often disconnected from the corporate network
  • gracefully handling remote deployment targets over unreliable or slow network connections

The best place to get started with elastic and transient environments support is our guide.

Cloud Regions

When we shipped Octopus 3.0 we thought we were on to a good thing with Azure Cloud Service and Azure Web App deployment targets - and we kind of were. The deployment targets addressed one set of needs, and the replacement Azure Cloud Service and Azure Web App deployment steps addressed another set of needs. We wrote more about this in an earlier blog post.

Now we have introduced Cloud Regions as a way to bridge that gap and make it easier to design rolling deployments for multi-region cloud applications. Based on this we will begin the process of deprecating the deployment targets. You can read more about this below and we will provide you will all the details you need to migrate as part of the upgrade guide in our documentation.

Proxy support for Tentacle communications

We have implemented support for HTTP proxy servers in the protocol used for Octopus Server to Tentacle communications. This works for both polling and listening Tentacles. Each Tentacle can be configured to use a different proxy if required. You can even use one proxy to connect a Tentacle to the Octopus Server, and a different proxy for general web requests.

Some notable omissions from Octopus Deploy 3.4 Beta 1

In order to get this beta release to our customers sooner, and work with your feedback, we made some difficult decisions.

  • In Beta 1 you can deploy releases using the web portal or the API, but you cannot use octo.exe or any of the build server extensions. We hope to have those updated in Beta 2.
  • In Beta 1 you can implement tenant-based security using one or more tenants explicitly, but you cannot use tenant tags in Beta 1. Instead of using tenant tags for now, simply add the tenants to your teams explicitly. We hope to have tenant-based security using tenant tags completed in Beta 2.
  • We decided to defer some of the extra features that would make working with large numbers of tenants and deployment targets easier.
  • We are planning to tweak the way we calculate which deployment targets are included in deployments for tenants, but we didn't have it finished in time for Beta 1. At the moment, deployment targets with no tenant filtering are considered as "available for all tenants". In Beta 1 the safest way to proceed is to use tenants for all your environments, including test environments. In Beta 2 (and onwards) we would like to simplify this model to be:
    • Tenanted deployments use tenanted deployment targets (targets with a tenant filter of some kind).
    • Untenanted deployments use untenanted deployment targets (targets without any kind of tenant filter).
  • We haven't finished reviewing our API, and we expect it will change between Beta 1 and Beta 2. We have taken care to build Octopus 3.4 using our typical API-first approach, but we want to review the API from several different perspectives before we consider it stable.

Breaking changes and deprecation notices

Deprecating Azure deployment targets

We are starting to deprecate support for the Azure Cloud Service and Azure Web App deployment targets.

Don't worry, in Octopus 3.4 you can view and edit existing Azure deployment targets, and start migrating them over to use Azure Cloud Service and Azure Web App deployment steps and Cloud Regions.

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 Healthy, HealthyWithWarnings, Unhealthy and Unavailable. You can continue to use the existing MachineResource.Status which can be either Online or Offline in Octopus 3.4, but we have marked the Status property as Obsolete and will be removing it in a future release.

Tentacle has been patched to work with Octopus 3.4

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.

What is still left to be done before we ship Octopus 3.4?

Apart from working with our fantastic Octopus community on feedback, we still need to:

  • Implement some extra features that would be nice to have when working with large numbers of tenants and deployment targets.
  • 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.

And some other things we're really excited to announce that weren't quite ready for Beta 1, but will ship in Beta 2:

Known issues

  • We are continuing to work on the dashboards which still have some display/data issues. Please feel free to write to us with your feedback on the dashboards so we can incorporate it into the final design.
  • Older Tentacles will fail to register with Octopus 3.4 with the following message: Octopus.Client.Exceptions.OctopusDeserializationException: Unable to process response from server: The given key was not present in the dictionary. - see breaking changes above.

Getting started with Octopus Deploy Beta 1

Try it out on our Beta 1 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 1 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.

Your feedback really does make a difference

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!

Tagged with: EAP New Releases

Related posts