What's new in Octopus 2.4
I just pushed the button on a pre-release version of Octopus Deploy 2.4. This release is bigger than Ben-Hur! Our last major release was almost two months ago, and it shows: we closed 79 issues in GitHub, and added a bunch big new features. It's so big that we'll be doing a free webinar about what's new in 2.4. Hope you can make it!
Here's a brief rundown of what's new in this release.
The most significant visible change in 2.4 is that we've added a new top-level area, called the Library:
Previously, NuGet feed settings and Library Variable Sets lived under the Configuration tab, which was for administrators only. Since we're adding a number of new features that are going to be shared across projects, we decided it was time to have a dedicated place for these settings to live.
Better built-in NuGet repository management
There are a number of tabs under the library, the default being the built-in NuGet repository.
You can click on any package to view a list of versions:
You can select packages to delete them, or click a version to view the details:
You can even upload packages directly from the UI, which is useful when deploying one-off utilities:
Packages in the built-in repository are now automatically cleaned up as part of your retention policies. Packages that are no longer used by any releases will be automatically deleted from disk when the corresponding releases are deleted.
This feature is, in my opinion, the coolest feature in 2.4. Step templates allow you to create reusable steps that you can use across projects. This feature actually began life as a pull request from David Sansum from Sporting Solutions, and we loved the concept. A huge thanks to David and Sporting Solutions!
Here's how it works. The step templates tab is where your templates live:
When adding a template, you can choose to use any of the built-in step types. For this example, I'll use a PowerShell script:
Give your template a name and description so that other people know what it's used for:
My script is going to stop a Windows Service, so I'll want people who use my step template to tell me which service they want to stop. I do this by defining parameters:
With my parameters defined, I can now define how my step template will run, and make use of those parameters:
Now this is the exciting bit. When defining the deployment process for any project, I can use my step template as if it was a built-in step:
When using the step template, the parameters that I defined are available to edit, and can be bound to variables:
I think this feature is going to unlock a ton of possibilities around being able to create reusable blocks of scripts or other steps. We'll be building a place for people to share their step templates in the future, so watch this space! :-)
If all of your deployments follow a similar pattern, it's tempting to create a set of reusable PowerShell functions to use between them. In the past, while it was possible, there was never a very nice way of being able to use share these functions easily.
Now in Octopus 2.4, you can use Script modules to define a set of PowerShell functions - essentially, a
You can then include the script module as part of a project deployment process:
Now, whenever you run PowerShell within that project, the module will be available. This means you can reference the module from a script step, or inside your
Deploy.ps1 and related files. During runtime, Octopus will ensure the module is on the Tentacle and loaded; there's no extra work to do:
Active directory groups in teams
The third highest voted suggestion on UserVoice is now done - you can link Teams in Octopus to Active Directory groups:
We need you help to test this out, as Active Directory integration is tricky at the best of times. If you're using AD and can try 2.4.1 out for us to ensure the group membership works, we'd really appreciate it.
With Octopus 2.0 we greatly simplified the permissions system by creating a handful of high-level roles. Some customers needed the ability to modify these built-in roles, however, or to define new ones. In 2.4, you can now define your own.
Roles can be found from the Teams page:
From there, you can add a custom role, or modify the permissions of the built-in roles:
Integrated Windows authentication
If you're using Active Directory authentication, users will now get the option to sign in using an integrated windows authentication challenge instead of typing their password directly:
Of course, if you sometimes need to sign in as a different user, or for some reason this doesn't work, you can continue to sign in the old way.
Keep a limited number of backups
Henrik implemented this in his first day on the job. You can now tell Octopus how many backups of the Octopus database should be kept:
Customizable release number strategies
When you create a release, Octopus attempts to generate a release number for you by incrementing the previous version number. You can now take more control over this behavior by editing your project settings. You can either tell Octopus to make the release number match the number of a specific NuGet package:
Or you can specify a format yourself using syntax like this:
Sometimes it can get confusing to work out where exactly you are in an application like Octopus. In 2.4, we added the ability to upload a custom logo for each project. This logo will appear in the top left corner when navigating your project:
You can change the logo from the settings page:
Try it out and tell us what you think!
Right now this version of Octopus is a pre-release, and while it fixes a ton of issues, it's always possible that it may introduce some. Since there are so many changes, we'd really love for you to download it and take it for a spin. I think the new features make it a pretty compelling upgrade!