February 2017 Summaries

Octopus Deploy introduced a feature called raw scripting to address scenarios where users cannot install dependencies like Mono and Calamari on their SSH endpoints. This feature allows scripts to be executed directly through an SSH connection without additional wrapping, enabling deployment on devices where installing these elements is not feasible. Raw scripting requires setting a project variable and configuring SSH targets, bypassing health checks for dependencies like Mono and Calamari, and utilizing variable replacement syntax for script execution. Additionally, Octopus Deploy offers a "Transfer A Package" step that moves packages without extraction, catering to needs such as processing through scripts or uploading to other servers. This feature aims to provide a streamlined, efficient deployment process for users seeking a minimalist approach to deploying applications on Linux servers or other platforms with limited installation capabilities.

Google's recent announcement of an attack capable of generating SHA1 hash collisions has raised concerns about the security of digital signatures, although it does not seem to directly affect SSL/TLS encryption. The SHA1 algorithm, already on its way out, is still used by Octopus Deploy in generating X.509 certificates for encrypting connections between its server and Tentacle agents. In response, Octopus plans to update its system to use SHA256 for new installations and provide ways for users with existing installations to switch to more secure certificates. While users can immediately mitigate risks by generating their own certificates, Octopus will soon automate this process to ease transitions. Additionally, users are advised to check if SHA1 is used elsewhere in their systems, such as in web frontend or third-party service certificates. The post provides PowerShell scripts for detecting SHA1 certificates, allowing users to enhance their security practices, and highlights a new certificate management feature in Octopus 3.11.

Octopus Deploy's Release 3.11 introduces a comprehensive Certificates feature designed to streamline the management and automation of certificates within deployment pipelines, addressing the complexity and inefficiency often encountered in these processes. Users can now store certificates in PFX, PEM, or DER formats, and utilize them as typed variables within Octopus, which can be expanded upon deployment to simulate object-oriented properties. The update includes an Import Certificate deployment step, allowing for easy integration into Windows Certificate Stores and the configuration of HTTPS bindings. Additionally, certificates can be exported in the original or modified formats, with options for private-key inclusion, and expiry notifications can be configured to alert users when certificates are nearing expiration. The Replace feature enables seamless updating of certificates by inheriting properties from the expired version, and the functionality is accessible via Octopus's HTTP REST API and .NET client library, facilitating integration into existing X.509 certificate management processes. Paul Stovell, the founder of Octopus Deploy, emphasizes the importance of user feedback for further enhancements.

Paul Stovell discusses the challenges and potential solutions for storing Octopus Deploy configurations in version control, emphasizing the limitations of synchronizing Octopus settings with Git due to issues like conflict resolution and scope management. Instead, he proposes a more flexible "Octopus Declarative" approach, leveraging a C# console application and the Octopus REST API to define and apply configurations programmatically. This method allows for better control over configuration management without the complexities of bi-directional Git synchronization. Stovell also highlights potential enhancements, such as drift detection and resource locking, and suggests that this approach could meet diverse use cases and improve user experience without requiring extensive rewrites or impacting other product developments. He invites feedback on whether this declarative approach meets user needs for version-controlled Octopus configurations.

Shannon Lewis discusses recent updates to Octopus Deploy, specifically enhancements to support various Azure environments beyond AzureCloud, such as Azure Germany and Azure China. Previously, users had to set special variables for Calamari to connect to these environments, which was not user-friendly and limited the functionality of the UI selectors for Azure steps. The update in Octopus Deploy 3.9 now allows users to specify environment and endpoint overrides directly in the Azure Account definition, enabling both the server and Calamari to utilize these settings and improving UI interaction. While existing methods of using variables will still work, the new approach simplifies the process and makes it more accessible. However, fully testing the feature has challenges, and further enhancements are planned to streamline the selection of environments through a UI dropdown. Feedback will be monitored to address any issues that arise.

Octopus Deploy 3.8.7 introduced a feature enabling deployments to environments without targets, aimed at improving flexibility in Elastic and Transient Environments. This project-level setting allows users to perform deployments in environments, such as those used for infrastructure or testing automation, where targets may not yet exist or be online, addressing challenges in scenarios like spinning up new environments or deploying to offline transient machines. The feature supports combining infrastructure provisioning and application deployment steps into a single project, especially in Immutable Infrastructure scenarios. Users must opt into this feature, as deploying to environments with no targets typically indicates an error. The feature reduces the need for auto deploy overrides, which were previously used to manage deployments to no-target environments by queuing tasks for specific releases when new targets appeared.

Paul Stovell recounts the transition of Octopus Deploy's documentation hosting from Atlassian Confluence, initially managed by QueryFoundry, to a GitHub-based solution following a significant service outage. The documentation, crucial for users, was knocked offline when QueryFoundry experienced a critical network failure, and the lack of recent backups compounded the problem. After an anxious wait and an eventual recovery of the data, Stovell and his team decided against continuing with QueryFoundry due to inadequate communication during the crisis. Inspired by a peer company, they opted to convert their documentation to Markdown and host it via GitHub, integrating it into their website using custom tools they developed. The incident underscored the importance of maintaining up-to-date backups, even for content hosted by third parties.

Octopus 2.0 enhances deployment processes by introducing support for rolling deployments, allowing sequential execution of steps across multiple machines, which is particularly beneficial when deploying to a large number of servers. This functionality provides the flexibility to deploy to one machine at a time or in batches, ensuring a more controlled and efficient deployment process. The new feature is implemented through child steps, allowing users to customize their deployment strategy to better suit the needs of their infrastructure.

Sensitive variables have been introduced in Octopus Deploy 2.0 to securely manage configuration data such as passwords, API keys, and encryption keys needed for applications in production. These variables are encrypted in the Octopus database, ensuring they cannot be retrieved through the API or UI, and efforts are made to prevent them from appearing in logs. However, they remain accessible for PowerShell scripts during deployment and can be inserted into configuration files, providing a balance between security and functionality.

In February 2017, Paul Stovell, founder and CEO of Octopus, shared an initiative by the Octopus cloud team to integrate support for Azure Service Fabric deployments into Octopus Deploy, following a popular UserVoice suggestion. Azure Service Fabric is a Microsoft platform designed to simplify the packaging, deploying, and managing of scalable and reliable microservices, addressing challenges in cloud application management. The proposed solution involves deploying Service Fabric applications using NuGet/zip packages, with a structured approach to package contents and a new step template for deployment. The process includes unpacking package content, performing variable substitutions, and utilizing Azure Service Fabric SDK and PowerShell scripts, while also allowing the use of custom Azure Fabric SDK versions. Versioning of NuGet/zip packages with Octopus and Service Fabric applications presents a complex challenge, as it involves handling code and configuration versions per service and application, and the Octopus team is actively seeking feedback to refine this feature.