Today I'm happy to announce that Octopus Deploy version 1.1 has been released. A lot of improvements have been made since the last 1.0 release, and in this blog post I'd like to walk you through some of those improvements.
The biggest change in this release is a conceptual one. Previously, an environment contained machines, and steps and variables pointed to those machines. From 1.1 on-wards, a machine will be tagged with one or more "roles", and those roles are what steps and variables will point to. I wrote about this change in detail in a previous blog post, so I'll use this post to walk through how the feature works.
When you edit a machine, you can now enter a list of roles:
You can enter any role name you like, and roles you've used before will appear using auto-complete (using the Select2 control). Roles might be general ("web-server"), or specific to your applications ("crm-batch-importer").
Note also that the machine above belongs to two different environments. Previously, you had to duplicate a machine, but now the machine can be moved between environments easily.
When you edit steps, you'll now choose which roles will receive the package:
Variables, however, can be scoped either to a role or a machine:
These changes create a number of benefits:
- Machines can be added or removed without a new release having to be created
- Machines can be moved between environments
- Variables can now more easily be scoped to a group of machines
Automatic Tentacle registration also supports this feature - just pass the
--role=my-role command line argument when using
Another new concept introduced in this release is the idea of a "project group". This provides a level of nesting for your projects, enabling them to be grouped and managed more easily.
For example, in one my internal Octopus Deploy installations, I have two groups - one for real applications, and one for samples:
The project settings page is used to configure a project group:
The projects menu will also display the projects using groups:
A project group has a name, and a list of environments that projects in the group are allowed to deploy to:
Here, you can see that my "Real Applications" project group is allowed to deploy to only two environments - Staging and Production. My "Sample Applications" project group, on the other hand, is only allowed to deploy to a Staging environment. This affects the layout of the dashboard, which is now broken into groups:
As well as which environments appear in the deployment screen for projects within the group:
In the future project groups will become even more important, as they'll become the place where retention policies and most permissions are set from. For now they're a great way to tame the dashboard.
We also introduced the concept of "favorites", to control which projects appear in the drop down menu. This is a per-user setting. You can mark a project as a favorite by clicking the star icon:
If you have any favorite projects set, then only your favorites will appear in the menu (if you haven't chosen any favorites, then the first 20 projects will appear):
The changes to support roles required a break from the old data model, so a few changes had to be introduced. Before you install the new Octopus Server, make sure to take a backup (you can do this from the Storage tab under Configuration in the Octopus web portal). Then, after installing the new Octopus Server, use the Start button on the Server tab in the Octopus Administration Tools. This will make a few changes to your existing projects to enable role support. I wrote more about the kinds of changes that will be made in this blog post (we went with option 3).
As you can see, 1.1 is a pretty big change. The next feature we'll be tackling is having the Octopus Server and Tentacles clean up after themselves to conserve disk space, a feature we're calling "retention policies", which will likely hang off of project groups.
Note that because of the number of changes in the release, we've also released a new version of Octo.exe.