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 - read the RFC and follow this GitHub issue for more details
- Improved elastic environment and transient machine support - read the two RFCs (cloud and infrastructure automation support and octopus reactions) and follow this GitHub issue for more details
Multi-tenant deployments in Alpha 2
In Alpha 2 you can:
- perform tenanted deployments using tenant-aware lifecycles
- configure deployment targets and accounts for use by specific tenants but note this is not enforced in Alpha 2.
- scope variables and steps to tenants by tag
- build library and project variable templates
- define variable values for your tenants
- select tenants by tag for all of the above, including a designer experience
- do all of this via the Octopus API and client library!
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:
- improved dashboards that can be pivoted by environment, tenant tag, channel
- variable inspector
- bulk tag editor and tenant rollup/dashboard to make working with lots of tenants much easier
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!
We think deployment-related controls should belong to a project
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 targetsstep 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 checkstep, 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?
- We are planning to change this step to become a
- 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.
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
Try it out on our EAP demo server using the guest account.
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?
Our EAP comes with a 45-day Enterprise trial license. Download the latest EAP release taking a look through the release notes. Since it is so early in the development phase we will not support upgrading from EAP releases. We recommend installing the EAP release on a trial server.
Your feedback really does make a difference
Please post any feedback and join the conversation in our discussion forum. We would especially appreciate feedback on:
- Is the "normal" and "tenanted" deployment concept confusing, or does it make sense to you?
- We are planning to exclude tenant variables from snapshots (so you can add them, and change details any time after a release is created). We also have long term plans to remove snapshots - what do you think?
- Is there anywhere else you think we should allow selecting/scoping to tenants?
- Is there something missing from the
Machine Policiesnow that we've refined them? - Do you see problems with the direction we're taking for auto-deployment?
Go ahead, get involved and help us build the best Octopus Deploy yet. Happy Deployments!
Octopus Deploy is used by thousands of developers across the globe, from small companies to large enterprises. Find out if it meets your deployment automation needs by taking advantage of our free 30-day trial. You can spin up an instance with just a few clicks!
