Thoughts on Octopus Deploy 2.6

Now that Octopus Deploy 2.6 was just released, I feel I can publish some of my opinions on it. I installed the pre-release on my Azure instance weeks ago just before Thanksgiving and I’ve just upgraded to the official release (2.6.0.778). Even though 2.6 is a minor update, it is a game changer. Changes listed on Octopus Deploy 2.6 are:

• Lifecycles to control promotion and automate deployments
• Automatic release creation from NuGet push
• Running steps in parallel
• Up to 5x faster package uploads
• Skipping offline machines

Lifecycles is a feature worth having. I’ve tried it out and I have to say, it’s great on a few levels. It adds a tangible process of where your packages will flow to in your environments. For many of our teams, I imagine over time they can leverage lifecycles as part of their process rather than use Octopus haphazardly to deploy to environments at inconsistent intervals.
There’s some minor tweaks all over the UI within Octopus but they’re all for the better. First, with lifecycles, you see things like this:

Lifecycles puts guard rails around your deployments. You can still adjust deployments as you want in clicking on the “Deploy to…” link next to the button, but this makes deploying that much more clear as to where the deployment is going within your lifecycle as the image of your lifecycle is clearly visible on the deployment page.
I think the lifecycle acts as a conceptual model for how teams leverage their environments to test their code, but when left to their own devices, teams go whichever way the wind blows. That is to say that in practice, teams do not deploy as they intended. They tend to carry over the habits from the non-automated deployment days and erratically or inconsistently move code throughout all their environments.

In turn having lifecycles brought about a feature that was easily done from the octo.exe but not within the UI; deploying to multiple environments at the same time. Deployments used to have a 1-to-1 relationship now can have a 1-to-many at the click of a button. If you click on the “Deploy to…” link, you’ll see that you can configure which environments to deploy to. You can select one or as many as you’d like.
If you haven’t gotten the gist yet, lifecycles doesn’t force teams to a set pattern, but it makes it easy for teams to follow through deployments to one (or more) environments at a time with the idea of phases. You configure phases to describe which is represented by the main branch within the lifecycle picture; each phase you tell what environments belong to that phase and the retention policy for that environment.
In the pre-release, lifecycles visually showed what teams did and did not deploy to their environments. This was a great idea albeit a little awkward implementation on the project dashboard. I wasn’t fond of the whole faded appearance starting from the bottom left hand corner of the dashboard but I understood its intent of making the previous releases more aged and less relevant compared to the newer releases on top. It was a minor blemish but not too distracting for me.

Just a quick glance tells you a complete story without all the nitty-gritty details. If anything, this newer view is a mere extension of the previous version of the overview where you would only see the latest deployment to all your environments.
You can see that per release (0.0.30, 0.0.31, etc.) which environments were deployed to. You can also see which releases were blocked (hence the yellow “!” warning icon). This project dashboard tells you a story which is clear in a matter of seconds.
My inner monologue sees this spreadsheet-esque view and screams “ugh.. not another spreadsheet”. But then the following microsecond I realize that I’m looking at the historical deployment for each release across all the environments and then my pre-frontal cortex goes “this is what I was looking for!” Huzzah for the Octopus Deploy team for extending an older implementation (the project dashboard on the overview tab) to the next logical step. Unfortunately, while this was in the pre-release, they had to remove it for 2.6 for performance reasons. If anything, this is something to look forward to in 3.0. Note issue 1392 as mentioned on the downloads page on the Octopus site.

 
While our use case specifically for the enterprise is a bit more cumbersome due to a large user base (over 500 users so far) lifecycles will require some education. We do plan to upgrade to 2.6 but not right away.
It seems like a silly notion of not deploying to all of your (non-production) environments but we see teams do it all the time. If something fails in an environment now, you can block the release with as shown now in the project dashboard from above. I think teams still carry over the old habits of not deploying through to all staging/testing environments because before Octopus, they wouldn’t do it because it took too long. Now teams can deploy with a press of a button to one or multiple environments. Where teams promote their package(s) to next can be a mystery and I think it’s the relic of the past. With automation and Octopus Deploy, there’s almost no reason not to deploy.
Unfortunately, automatic release creation for me won’t be used as we use external feeds, not the internal NuGet feed in Octopus. I can give it a test shot but we can’t really use it with so many teams to support (now over 120), the notion of putting all packages from those teams is untenable. Running steps in parallel I can see as a huge reduction in deployment time for projects with multiple NuGet packages in their deployment process; beyond that, I can’t imagine too many scenarios but having it available nonetheless is valuable.  It all depends on your steps and custom PowerShell scripts that may or may not benefit from parallel steps.
Currently, my test NuGet packages are very small so I can’t really tell how fast the package uploads are but I’m sure I could try out a few new tests with some varying packages sizes and contrast/compare speeds from versions. Don’t hold me to this, but I may give this a whirl pending how much free time I have. Skipping offline machines is nice but most of our tentacles are online so it’s a nice feature to have.
Octopus Deploy has really cranked out a lot of changes – each version with a great set of features that really adds value. As a developer today – I can’t imagine working without automated deployments. If you’re still sitting on the sidelines debating what tool to implement, I highly recommend Octopus Deploy version 2.6. You won’t regret it.