July 2016 Summaries

Octopus Deploy 3.4 introduces the concept of elastic and transient environments, which enhances support for environments where machines frequently change. Key features include machine policies, which allow customization of health checks, updates, and the handling of offline machines; a health check step that integrates into the deployment process to ensure machines are online; project triggers that automatically deploy updates when new machines are added; and project machine connectivity settings, which help manage deployments by skipping offline machines to prevent failures. These features are designed to streamline the management of dynamic environments, making it easier to maintain up-to-date deployments in changing infrastructures.

Octopus Deploy 3.4 introduces support for Semantic Versioning 2.0.0 (SemVer 2.0.0), enhancing the way pre-release versions and build metadata are handled. The new version allows for more flexible and precise versioning, addressing previous limitations by enabling numeric and lexicographical ordering for pre-release identifiers and introducing a separate component for build metadata that does not affect version precedence. Octopus Deploy 3.4 supports SemVer 2.0.0 for release numbers and packages, and it includes new capabilities for creating and consuming SemVer 2.0.0 NuGet packages, though full support for creating such packages with OctoPack is not yet implemented. The changes aim to improve versioning clarity and consistency in deployments within Octopus Deploy and its associated tools and plugins.

Octopus Deploy 3.4 introduces support for F# 4.0, allowing users to write custom and standalone scripts in this language alongside existing support for Bash, PowerShell, and ScriptCS. The decision to include F# was based on user requests and its unique features, such as compact syntax, strong type inference, and explicit handling of edge cases, which provide a versatile alternative for deployment scripts. The update is part of the Octopus 3.4 blog series by founder Paul Stovell, who encourages users to explore F# through resources from the F# Foundation and educator Scott Wlaschin. Additionally, the platform allows for executing arbitrary F# code on multiple targets using the Script Console, enhancing flexibility in deployment workflows.

Octopus Deploy 3.4 Beta 2 has been released, marking a significant milestone as the version is considered feature complete, aside from minor enhancements and bug fixes. This update introduces several new features, including support for multi-tenant deployments, elastic and transient environments, and the ability to write custom scripts in F#. It also upgrades to NuGet v3 with SemVer 2 support and offers improved tools and integrations, such as octo.exe and extensions for TeamCity and VSTS. The release moves proxy configuration to the Environment area, deprecates certain Azure deployment targets, and introduces changes to health check results and repository error codes. While older Tentacle versions require updates to work with Octopus 3.4, the new version aims to enhance automation and streamline the deployment process. The release encourages feedback from the community as further improvements are planned, particularly for scaling large installations and migrating tenants using the API.

Octopus Deploy 3.4 introduces multi-tenant deployments, allowing releases to be deployed to multiple customers in a safe and repeatable manner. This feature addresses the need to manage custom variables per tenant, particularly important for customizable SaaS applications, by using Variable Templates. These templates specify necessary variables for successful deployments either on a project or a library variable set, with project templates allowing environment-specific values and library templates offering constant values across projects and environments. Tenant-variable snapshots are not taken, which allows for the addition of new tenants and modification of tenant-specific variables without needing to create new releases. This flexibility enhances the deployment process by enabling immediate implementation of changes and reducing the need for extensive release cycles.

Octopus 3.3.21 introduces a feature that allows standalone scripts to accept command line parameters directly, eliminating the need for previous workarounds that required using the Octopus API to fetch variable values. This enhancement simplifies the testing of "normal" scripts outside of Octopus, as users no longer need to create additional wrapper scripts or manage extra files. Parameters must be provided in a language-specific format, such as using "-Parameter1 Value1" for PowerShell or simply "Value1 Value2" for Bash, which the system then passes directly to the execution environment, enhancing the ease and efficiency of script parameterization.

Octopus Deploy 3.4 introduced multi-tenant deployments, adding a new dimension to deployment management by allowing the same release to be deployed in different environments for various tenants, each with their own set of variables, machines, and permissions. This feature is additive, meaning existing projects can continue without modification until tenants or tags are actively used, making the transition seamless for users not immediately needing this complexity. Multi-tenant deployments enable more granular control over deployment processes, allowing for specific configurations such as scoping machines to particular tenants or adding tenant-specific deployment steps, which can enhance the deployment architecture for users requiring such precision. The design choice to avoid automatically creating a default tenant helps prevent potential confusion and blockages in existing projects by keeping un-tenanted deployments straightforward. This approach aligns with Octopus Deploy's philosophy of minimizing disruption for users not ready to adopt new features while providing powerful tools for those who need them.

The blog post by Michael Richardson discusses the process of deploying an ASP.NET Core application to a Red Hat Enterprise Linux server using Octopus Deploy, following a demonstration by Scott Hanselman. It highlights the challenges faced by .NET developers unfamiliar with Linux and provides a detailed technical guide on setting up the necessary components, such as Mono, NGINX, and Supervisor, while emphasizing the importance of using official documentation to counteract the rapid obsolescence of technical procedures. The post also mentions the use of Octopus features like JSON Configuration Variables and Variable Substitution for configuring deployment settings and underscores the future direction of Octopus Deploy, which aims to eliminate the need for Mono and scripting by leveraging .NET Core for cross-platform deployments. The author invites feedback from users deploying .NET Core applications to Linux, emphasizing the continuous improvement of deployment processes.

Octopus Deploy 3.4 introduces the eagerly awaited multi-tenant deployments feature, addressing a significant demand from users who manage multiple customer deployments. Originally planned for earlier releases, its development was delayed due to design pivots, particularly around Azure deployment targets, and the introduction of other features like Channels. The development process heavily involved community feedback through methods such as RFCs, an Early Access Program, and beta testing, which reshaped the feature into a more user-aligned and first-class entity in Octopus Deploy. The multi-tenant deployments feature is now available in beta, allowing users to deploy the same release to multiple customers while maintaining the integrity of existing systems. This release highlights the importance of community-driven development in refining large features to better meet user needs.

Octopus Deploy 3.4 introduces new features focused on elastic and transient environments, specifically through the development of machine policies and project triggers designed to enhance auto-deploy capabilities. The journey to these features involved numerous iterations and challenges, including initial complications with the user interface and the need for a more streamlined approach to deployment logic. The team explored various architectural solutions, ultimately settling on an event-sourcing architecture that improved functionality and high-availability performance. This involved combining elements from an earlier domain-events architecture to effectively manage deployments across different environments. The features, currently in a beta release, emphasize the separation of deployment logic from machine policies to projects, allowing for greater flexibility and precision in deployment processes. The development process was marked by a commitment to exploring all possible solutions to achieve the best outcome for users, resulting in a system that is both innovative and responsive to user feedback.

Octopus Deploy 3.4 introduces expanded proxy support, allowing both Polling and Listening Tentacles to communicate through proxies, which was previously limited. This update enhances the flexibility of network configurations by enabling the use of different proxy servers for different Tentacles and eliminates the need for special firewall allowances in many cases. The changes are facilitated by teaching the Halibut communications library to operate through proxies, overcoming the limitations of previous versions that relied on .NET's System.Net.WebRequest. Users can set up proxy details in the Octopus configuration for Listening Tentacles, while Polling Tentacles require proxy setup during installation. This release aims to simplify and expand deployment options for users working within network-restricted environments.

Octopus and Tentacle, initially built against .NET 4.0, are transitioning to .NET 4.5 due to several compelling reasons, despite initial reluctance caused by potential breaking changes and lack of support for Windows Server 2003. With .NET 4.5 released in 2012, most compatibility issues are expected to have been resolved, and Windows Server 2003 has reached its end-of-life, diminishing the need for continued support. The transition to .NET 4.5 facilitates the use of TLS 1.2 for secure communications and access to newer libraries, such as the latest Azure libraries, enhancing the functionality and security of Octopus and Tentacle. As a result, Octopus 3.1 and Tentacle 3.1 will require .NET 4.5, although previous versions remain available for those unable to upgrade.