Octopus Deploy Series Conclusion

Over the past few months, I’ve tried to show how Octopus Deploy works, how the design choices that the Octopus team made affect you and why these choices are beneficial. In retrospect, deployments should have evolved in parallel to the technology at hand, but history does not support that thesis. Deployments can be unique and complex and considering the wide range of components involved it’s easy to see why so little progress has been made. From operating systems, databases, patches, updates, configuration settings, network addresses, ports, firewalls, services, windows services, web services, web sites, reports, etc., there are too many components, settings and layers of administration to deal with.
It’s unfortunate that many organizations (still) have deployments relegated the role of the ugly duckling. Deployments are typically an afterthought. As developers, we tend to focus so much on the details of building or maintaining applications and not on how to deploy changes quickly, reliably and across environments. It’s the job no one wants because deployments are complicated (especially when things go wrong). But today, it’s my contention that for Windows .NET development, Octopus Deploy and NuGet has solved this awful task.
Octopus Deploy tackles deployments from a uniquely simple and adaptive perspective. Despite Octopus Deploy’s first attempt didn’t quite hit the mark, the Octopus team reevaluated some decisions and made the choice to change from lessons learned from the 1.0 version. On the second time around, they got it right. At first glance, these decisions (RavenDB and NancyFX) appear trendy and somewhat superficial but after digging in a little further, you can see they were deliberately chosen and when combined together with NuGet, elegantly addressed the problem of deployments while still allowing for a large degree of flexibility. As a result, we as users and developers have greatly reaped the benefits.
By ditching the old tried-and-true platforms (SQL Server and IIS), they’re free from the anchors to the past ways of tackling problems. Is a SQL database a key factor for success for automated deployments? Does IIS have such an advantage over another web host that gives an edge in solving the automated deployments dilemma? Apparently not.
Is this to say SQL Server and IIS are bad products? Of course not. They’re both extremely mature products and each have their strengths which are applicable to the majority of use cases. But after using both SQL Server and IIS for Octopus 1.0, the Octopus team concluded that for automated deployments, they simply weren’t necessary. By removing SQL Server and IIS, they’ve avoided all the headaches of troubleshooting, compatibility issues, verbose and lengthy installations while adding value to their mission of enabling teams to deploy software more reliably, repeatably and with less risk.
You can read about the switch from SQL Server to RavenDB here on the Octopus Deploy blog. They also mention Nancy on another blog post here when discussing Octopus 2.0. I’m not going to rehash what they say about switching to RavenDB and NancyFX, but I think it’s safe to say that there’s nothing to gain by switching back to SQL Server and IIS.
Using NuGet was brilliant. I’m not sure who gets the credit for that decision but by going with NuGet, Octopus solves one of the biggest problems with deployments – moving files from server to server in a consistent, secure manner. In addition to the transportation aspect, using NuGet absolves the TFS build server having to retain multiples of build folders thus reducing the total storage needed. All this with security such as HTTPS, API keys, along with metadata in each package allow you to rollback your application in an easy, consistent manner.
At first, I thought the lack of integration with Visual Studio and TFS would be a major hurdle to overcome. I’ve since learned to view this lack of integration as an advantage as it can lead to flexible configurations of your builds generating NuGet packages and continuously deploying releases without disrupting or adding additional steps within a developer’s workflow.
Another point I’d like to mention is logging. No one has rivaled this feature like Octopus does. When deploying your release to a specific environment, everything is logged, chronologically, across multiple servers within your environment and visible from one page. You don’t have to do anything to have this functionality, it’s baked right in and works with your PowerShell scripts too. You can view it in real-time and all the information is saved with each release so there’s no need to setup or configure anything.
My final point on Octopus that stands out is by far the community. The user forums, the user voice site where you can suggest ideas, and the Octopus Library, the community is a huge asset that needs to be given credit to both the Octopus team and the community itself.
In late 2013, I started a project where I was testing both Microsoft/InCycle Release Management 2013 and Octopus Deploy. In my first few weeks with Release Management 2013, while it’s features appeared to be very impressive, my experience was otherwise. While there were plenty of features and capabilities touted, we ran into problems which were with the simplest of tasks. Each deployment was a bit of a chore and trying to view all the information per release was fragmented. And all the while we had numerous issues with connectivity as the network I was working with was worldwide with multiple data centers and not one port available to all areas. This specific issue is not a fault of Release Management, but rather our environment. But shouldn’t an enterprise level product be more flexible for the environment for which it is to be used? Perhaps I’m in the minority in that opinion. I still think Release Management has value for deployments, but it’s benefits are highly dependent on the situation in which it’s implemented.
After testing Release Management, I started testing Octopus Deploy and I slowly began to see the power, elegance and how effective it was at deployments. I was floored by how simple it was and just how much customization you can do all through PowerShell (Release Management can use PowerShell as well – FYI).
After spending a lot of time with Octopus Deploy, it was clear that design philosophy was probably one of the key factors that differentiate Release Management from Octopus Deploy. Release Management was very heavy handed as it needed to work with a wide variety of products with numerous tools while Octopus tried to be light and nimble. For better or worse, the decisions make sense for each product. Release Management catered to wide variety of Microsoft products right out of the box. Where as Octopus requires a lot more PowerShell to accommodate most Microsoft products. Which is the better approach is subjective to your own needs, but we’ve managed very well with Octopus Deploy.
Is Octopus Deploy perfect? Probably not, but the foundation has proved to be worthy. We could say Octopus Deploy isn’t even fully finished, but with all the updates and community feedback the future is looking very bright. But the here and now matter most and I can’t speak highly enough for Octopus. If you’re looking to manage your deployments or get into continuous deployments, give Octopus Deploy a chance and you’ll see what I’ve been rambling on about.

Thanks for reading my Octopus Deploy Series. This concludes the series, but in a few weeks, I’ll be publishing my deep dive series where we’ll go into detail about specific features and scenarios within Octopus Deploy.