Octopus cowboy emoji

Octopus Deploy 3.4 EAP - Alpha 2

Paul Stovell

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

We are proud to announce the release of Alpha 2 as part of the Early Access Program (EAP) for Octopus Deploy 3.4! This feature release is ambitious, and we want to get it in your hands earlier, rather than waiting to ship a nearly-baked pre-release. Now is absolutely the best time to get involved and let us know what you think!

What will Octopus Deploy 3.4 look like when it ships?

We are targeting two major sets of features for the full release of Octopus Deploy 3.4:

Multi-tenant deployments in Alpha 2

In Alpha 2 you can:

Multi-tenant sample in Alpha 2

We have built a small utility that drives the Octopus API to install the full multi-tenant sample (shown in the demo video above) into your Octopus 3.4.0 Alpha 2 server. Download Octopus.Sampler.1.0.0.zip and look at the EAP page for more details.

Still to come for multi-tenant deployments

We’ve made a lot of progress but there are still some important pieces left to build:

Machine policies in Alpha 2

Based on your feedback (yes it really helps!) we have refined the concept of machine policy, and in Alpha 2 we think machine policies is feature-complete.

In Alpha 2 you can:

  • Control the frequency of health checks
  • Customize the health check script (starting with what we do today as a baseline/default), allowing you to control the result of the health check, which now results in Healthy, Healthy with warnings, Unhealthy, Unavailable (was offline, but we want to avoid confusion with offline drops)
  • Indicate which machines are expected to be unavailable from time-to-time to reduce noise in your health check results (previously an unavailable machine resulted in a machine being unhealthy and errors in your logs)
  • Control what to do when a machine is unavailable for too long

Other possibilities we are considering:

  • Lock Tentacle to a particular version because you are running .NET 4.0 on some servers
  • Automatically upgrade Tentacle instead of pestering you on the Environments page
  • Automatically upgrade Calamari instead of pestering you on the Environments page

What about auto-deployment, and skipping machines that aren’t available for a deployment? Read on, dear reader!

In Alpha 1 we attempted to fit everything into machine policies. Upon reflection (and your feedback) we’ve decided to move the deployment-related controls into the project. It is really the deployment process that determines whether deployment targets can safely be skipped, or included mid-deployment, not the machine policy.

In Alpha 2 you can:

  • Use the new Evaluate deployment targets step at different points in your deployment process to figure out which deployment targets should be included in the following steps (based on latest health check result, or running a connectivity check, or a full health check)
    • We are planning to change this step to become a Health check step, which allows you to perform a health check, and decide what to do: fail the deployment, continue the deployment ignoring unavailable/unhealthy machines, and potentially adding newly available/healthy machines to the deployment. What do you think?
  • Indicate that certain deployment targets should be skipped if they become unhealthy or unavailable during the deployment (think scaling down during a deployment)

Introducing triggers for auto-deployment

A little while ago we wrote an RFC for something we were calling Octopus Reactions. The concept is you can define triggers based on certain Octopus events, and then actions to perform in response. We think triggers and actions provide a better way to model auto-deployments. We are planning to implement auto-deployments using triggers for Octopus 3.4. Follow this GitHub issue for more details.

Imagine configuring a trigger when a machine with the web-server role becomes healthy (filtered by environment), you could trigger the deployment of your project(s), running steps specific to that web-server role, and somehow selecting which other steps should/should-not run as part of this auto-deployment.

Work in progress - Triggers

Triggers are still a work in progress so you cannot configure auto-deployments in Alpha 2, but we are keen to get your feedback based on this screenshot. What do you think?

Getting started with Octopus Deploy Alpha 2

Want to install it yourself?

Octopus Deploy comes with a 45-day Enterprise trial license. 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.

Go ahead, get involved and help us build the best Octopus Deploy yet. Happy Deployments!

Tags:

Paul Stovell

Related posts