Octopus Deploy 3.6 is here! It seems like only yesterday 3.5 was released. For long-time Octopus fans, two minor version bumps so close together may come as a surprise; we're trying a new approach to versioning.
Versioning strategy
Our aim at Octopus is to deploy bug fixes and features as soon as they are ready. We believe that the code we write is most valuable when it is in your hands, where features make your life easier and bugs are short-lived.
Traditionally we have released bug fixes and small features as patch versions (for example 3.2.1, 3.2.2, 3.2.3) and released large features as minor versions (for example 3.1, 3.2, 3.3), often bundling a bunch of features into the same minor version release. Starting today, we are experimenting with releasing a minor version as soon as a feature is ready (rather than bundling) or when upgrading from the previous version might cause friction.
In today's release, 3.6, we increment the minor version because upgrading from 3.5.x might cause friction. We want to ensure that you can apply patch releases with your eyes closed: it will be smooth, painless and everything will continue to work as it did before. You will be able to move between patches, so if you encounter a patch you don't like you can roll back to your previous version.
A minor version increment signifies that you may need to pay a bit more attention to the upgrade and you will only be able to roll forward. In today's release there is a schema change that affects Project Triggers, which includes an upgrade script that will convert version 3.5 Project Triggers into version 3.6 Project Triggers. The only way back is to restore a database backup!
Project Trigger changes
Event filters
In Octopus Deploy 3.4, a Project Trigger could be configured to automatically deploy based on two events:
- A new deployment target becomes available
- An existing deployment target changes state
We have listened to feedback that it is not entirely clear what these two events mean. In Octopus Deploy 3.6, you can select any machine-related event to cause an automatic deployment (aka. Project Trigger) to fire. We have also provided a convenient event-grouping mechanism (as introduced in Subscriptions) to select a pre-defined group of events:
The events that can be selected in the Project Trigger filter map exactly to the events shown on the Configuration > Audit screen to make it easier to design and troubleshoot Project Triggers. The ability to select any machine event also opens the door to configuring some interesting Project Triggers. For example: attempting to heal a machine if it becomes unhealthy.
Machine selection logic
"Auto-deploy is hard!"
The automatic deployment feature began life as a magical checkbox that kept machines up-to-date with the latest releases. We soon realized that getting the correct releases to the correct machines was hard. In an attempt to determine if "a new deployment target became available" or if "an existing deployment target changed state" we performed some complex calculations which, for the same sequence of events, would sometimes yield an automatic deployment and sometimes not. In 3.6 we have done away with the complexities. Instead, when an event occurs that matches the filter that has been chosen for a Project Trigger, that Project Trigger will fire.
The event filter on any existing Project Triggers will be updated with 3.6. "A new deployment target becomes available" will be converted to execute on the "Machine created" event and "An existing deployment target changes state" will be executed on the "Machine becomes available for deployment" group of events.
What's next?
We hope you enjoy 3.6 and find that Project Triggers have more depth and predictability. We anticipate expanding on Project Triggers by opening up event selection to include more events and by providing more actions that can be executed as a result of a trigger firing. For example, you may be able to configure a Project Trigger to "automatically deploy Project B after every successful deployment of Project A" or "create and deploy a release to the Test environment when a package is pushed".
