Octopus Deploy 3.4 EAP - Beta 1
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?
- Breaking changes and deprecation notices
- Some notable omissions from Octopus Deploy 3.4 Beta 1
- What is still left to be done before we ship Octopus 3.4?
- Known issues with Octopus Deploy 3.4 Beta 1
- Getting started with Octopus Deploy Beta 1
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 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.
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.exeor 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
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.
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:
- You will be able to 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 are replacing our dependencies on NuGet.Core by upgrading to NuGet 3 across the board, which means we will finally be able to close some long-term bugs, and support external NuGet v3 feeds! See this GitHub Issue for more information.
- You will be able to use SemVer 2 versions in releases and packages!
SemVer 2.0 support in @OctopusDeploy is coming…— Michael Richardson (@mj_richardson_) June 20, 2016
It just passed the Works-On-My-Machine test. pic.twitter.com/phgOH7bNAx
- 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!