December 2016 Summaries

The blog post by Robert Wagner discusses the integration of Azure Functions and Amazon's Lambda with the Octopus REST API and Subscriptions Feature to automate tasks beyond Octopus's built-in capabilities. It describes two specific examples of such integrations: managing unclaimed manual interventions in deployments and handling offline machines. For unclaimed interventions, a C# Azure Function regularly checks for unassigned manual tasks and sends SMS notifications using Twilio if they remain unaddressed for over a minute. For managing offline machines, another function is triggered by Octopus subscriptions when a machine becomes unavailable, deciding whether to delete the machine or take remedial action, with notifications sent via SMS. The post provides detailed setup instructions for both examples, including using the Octopus.Client library, configuring app settings, and testing the functions. It also highlights the use of external systems for potential full implementations and offers resources for further reading and code samples.

Octopus Deploy's latest release enhances the user experience by improving the UI for adding step templates and integrating a Community Library, which provides direct access to over 200 community step templates. This update includes a fast search tool to navigate these templates and allows users to install, customize, and manage updates from the Community Library directly within a project's deployment process. The Community Library, enabled by default, facilitates the sharing and updating of step templates, although users who save community templates as custom ones will not receive updates from the original authors. BlueFin users upgrading to Octopus 3.7 need to disable the Integrated library step template importer feature. The step template library UI has been updated for better management, and Octopus now checks for matching parameters to link steps to community templates, with a more relaxed rule for linking in version 3.7.2. A new run feature allows admin users to test step templates with parameters independently of the deployment process. An anticipated feature to update steps to the latest version was delayed due to a bug, but a fix is forthcoming.

PowerShell Desired State Configuration (DSC) is a declarative approach to server configuration that contrasts with the imperative nature of standard PowerShell scripts, enabling tasks such as installing Windows features and setting environment variables during server provisioning. This text explains how Octopus, traditionally an Application Release Automation tool, integrates with PowerShell DSC to effectively manage, test, and deploy configurations, offering features like health checks to detect configuration "drift" and automatic deployments to correct it. By using Octopus, users can bypass the need for separate DSC push/pull servers, leveraging Octopus and Tentacle's secure communication modes for deploying DSC scripts. The text provides a walkthrough of setting up a demo environment, creating a simple DSC script to set an environment variable, and using Octopus to manage the deployment and test configurations. It highlights Octopus's ability to promote DSC script changes across environments and details how Octopus's recent features, such as automatic deployment triggers and custom health check policies, enhance its capability as a configuration management tool alongside PowerShell DSC.

Octopus Deploy 3.6 introduces a new versioning strategy aimed at releasing minor versions as soon as features are ready, rather than bundling them, to minimize upgrade friction and expedite the delivery of new functionalities and bug fixes. This release includes significant changes to Project Triggers, allowing users to select any machine-related event to trigger automatic deployments, thereby providing more flexibility and predictability. The update simplifies the machine selection logic by eliminating complex calculations and aligning event filters with those shown on the Configuration > Audit screen. Additionally, the release includes a schema change affecting Project Triggers, requiring a database backup to revert to an earlier version. Looking forward, Octopus Deploy plans to expand Project Triggers by incorporating more events and actions, such as deploying projects based on the success of other deployments or triggering releases when packages are pushed.

Automating SQL Server database deployments can be challenging, but a structured approach using change scripts and tools like DbUp can simplify the process. The strategy involves creating scripts for every database change, which are then stored in source control to maintain a clear history and ensure consistent deployment across development, QA, and production environments. DbUp, a class library called from a console application, is used to execute these scripts, with the ability to track executed scripts via a SchemaVersions table, enabling seamless updates and eliminating the need for shared databases. Although Octopus Deploy is often used to streamline deployment, the process described is independent of it, relying instead on a console app to manage script execution and configuration via a connection string in an app.config file. The final step involves packaging these scripts and console app into a NuGet package, which Octopus Deploy can then use to manage deployments, allowing for environment-specific configurations via variables. This method, while one of many, provides a robust framework for achieving automated database deployments.