February 2021 Summaries

Josh Duffney emphasizes the importance of starting with a centralized repository when beginning automation to maintain simplicity and clarity in organizing code. While a centralized repository is beneficial for teams or organizations new to automation, as it provides a single source of truth and is easy to manage, it eventually becomes cumbersome as tasks become automated and workflows increase. Over time, friction and slow development indicate the need for refactoring. Duffney suggests using value stream mapping to visualize current processes and identify opportunities for decoupling code into separate repositories, focusing on those changes that offer the highest return on investment. The goal is to balance simplicity and efficiency, ensuring that the repository structure supports automation without adding unnecessary complexity.

Bob Walker's article addresses the common question of whether to create a separate Octopus Deploy project for each application component or to manage all components within a single project. He suggests that having a project per component can minimize downtime, reduce build time, and simplify decision-making, although it complicates the coordination of releases. The article introduces a step template called "Deploy Child Octopus Deploy Project" to streamline release management by allowing users to deploy multiple components independently while coordinating them through a parent project. This approach includes features like automated approvals, scheduling deployments, and customizing parameters to fit various use cases. Walker also discusses alternative methods, such as using channels or disabling steps during deployment, but argues that these do not scale well or introduce manual complexity. Despite the complexity of setting up a project-per-component structure, the benefits of reduced deployment time and increased reliability make it worthwhile, especially for applications with components that change frequently and have varied deployment requirements.

Octopus Deploy is enhancing its communication strategy for disclosing product security vulnerabilities by introducing Octopus security advisories. Previously, vulnerabilities were communicated through CVE databases and release notes, assuming customers would check these regularly. The new advisories will consolidate release notes, CVE details, and additional information in one accessible location, providing details such as vulnerability severity, affected versions, and known exploits. These advisories will be posted on advisories.octopus.com and linked on the Octopus Deploy Twitter feed. The initiative aims to better inform and protect customers against potential security risks by ensuring they have comprehensive and easily accessible information.

Canary deployments in Amazon ECS allow for a gradual rollout of new application versions by directing a portion of user traffic to the new version while monitoring for any issues. By using CloudFormation, ECS can integrate with CodeDeploy and support Blue/Green deployments, providing flexibility to configure custom deployment strategies such as time-based canary or linear rules. These strategies allow traffic to be shifted incrementally, either automatically or manually, based on inputs like error logs or support requests. The blog post demonstrates managing ECS canary deployments with CloudFormation, detailing the use of ECS resources like TaskDefinitions, Services, TaskSets, and TargetGroups to manage tasks and direct traffic effectively. It also explains how to update task definitions and traffic rules to progressively direct more traffic to the new version, with the option for manual intervention to ensure the stability and reliability of the deployment. This method supports both Blue/Green and canary deployments, offering a flexible and repeatable process for testing and transitioning between application versions.

Shawn Sesna's article explains the process of creating temporary, containerized workers on the Azure platform using Octopus Deploy, highlighting the benefits of containers for short-lived tasks. The approach involves creating a runbook that includes steps such as setting up an Azure Resource Group and running an Azure Resource Manager (ARM) template to automate the deployment of an Octopus Deploy Tentacle container. A health check is performed to ensure the container's readiness, followed by the installation of necessary software components like PowerShell Core, Azure CLI, and AWS CLI to enable interaction with cloud platforms. Sesna also notes the flexibility provided by containers in avoiding the need to manage virtual machines, and the technique of using the Script Console to execute commands across all workers in a pool via API calls. The post serves as a practical guide for leveraging container technology to efficiently manage temporary workloads in a cloud environment.