July 2015 Summaries

Octopus and Tentacle, originally built on .NET 4.0, are transitioning to .NET 4.5 to leverage its enhanced capabilities, including support for TLS 1.2 and newer libraries such as the latest Azure libraries. Although .NET 4.5 has some minor breaking changes and is not supported on Windows Server 2003, these concerns have diminished over time, as Windows Server 2003 reached its end-of-life and most applications have addressed compatibility issues since .NET 4.5’s release in 2012. This move, outlined by Octopus founder Paul Stovell, will apply starting with Octopus 3.1 and Tentacle 3.1, while previous versions will remain available for those unable to upgrade.

In a reflection on changes made to Octopus Deploy's integration with Azure cloud services, Paul Stovell discusses the design shift introduced in version 3.0, which aimed to unify deployment targets by treating Azure cloud services like other targets such as Tentacles. However, this approach proved problematic because Azure services are not as reusable as other types, leading to a decision to revert to the earlier method used in version 2.6. This reversion in version 3.1 will reinstate the use of variables for deployment, while maintaining some improvements from version 3.0, such as the ability to run deployments directly from the Octopus server and enhanced UI features for Azure PowerShell scripts. Users of Azure services are advised to remain on version 2.6 until the release of 3.1, which will include a migration path for Azure deployment steps.

Octopus Deploy provides a system for scoping variables to different environments, roles, or machines, which is particularly useful for scenarios like using different database connection strings in Test versus Production environments. The concept of "variable specificity" in Octopus is akin to CSS specificity, where variables can be defined with multiple scopes, and the most specific scope takes precedence. This specificity is calculated through a ranking system that assigns scores based on the scope level, with machine-specific scopes being the most granular. Challenges arise when multiple scopes match a scenario, leading to potential non-deterministic outcomes, especially when roles overlap. The complexity of these specificity rules can make it difficult to intuitively understand which variable should apply, so it is suggested to model deployments in a way that avoids reliance on complex specificity matrices. Founder Paul Stovell highlights the importance of clarity in deployment modeling to prevent confusion for future users.

Paul Stovell discusses a method for managing multiple deployments of a website in a testing environment by using port numbers derived from the release version. By leveraging a PowerShell script, the process calculates a port number for each deployment using the modulo operator on the version's build number, allowing for the retention of a specified number of recent deployments. This approach ensures that older versions remain accessible even after new ones are deployed, with configurations made in the IIS feature of the package step. The port number is stored as an output variable, which can also be used to notify testers via email about new releases and their corresponding port numbers, offering an efficient solution for managing deployment environments.

Octopus 3.0, announced by Paul Stovell on July 20, 2015, represents a significant overhaul of the deployment automation tool, marking it as production-ready after eight months of extensive development involving major architectural changes. The update includes a transition from Raven to SQL Server, open-sourcing deployment execution code, revamping the communication stack, and rewriting deployment orchestration. Additionally, new features such as expanded deployment targets, a data migrator for JSON format, delta compression, a revamped user interface, and enhanced project overview were introduced, alongside efforts towards enabling High Availability. The release, which involved 1,790 Git commits, was rigorously tested through a comprehensive beta process with over 100 installations and multiple bug bashes. Stovell highlights the creative journey of software development and acknowledges his team's contributions to bringing Octopus 3.0 to life, expressing eagerness to resume a more frequent release schedule to continually improve the software.

Octopus Deploy licensing involves purchasing a perpetual license with one year of support and maintenance, allowing customers to use their current version indefinitely and upgrade during the maintenance period. The policy changes allow free patch releases if users qualify for the corresponding major or minor release, whereas major and minor releases require a valid maintenance date due to feature updates. To qualify for the 3.0 release, users with an existing 2.0 license must have a valid maintenance date on the release day or renew their license if expired. Octopus offers three editions of its software, with each edition allowing different limits on projects, deployment targets, and users, and customers can upgrade by paying the difference in price, which also resets the maintenance period. Each paid license permits three instances of Octopus Server, with discounts available for multiple licenses within a company, and customers can contact sales for upgrades or additional licenses.