May 2018 Summaries

Ben Pearce's post from May 31, 2018, provides a comprehensive guide to dynamically creating and tearing down Azure infrastructure using Octopus Deploy, specifically for deploying web applications on-demand for testing purposes. The guide discusses the introduction of new dynamic target cmdlets in Octopus Deploy version 2018.5, which simplify the management of Azure deployment targets by allowing the creation and deletion of resources like Resource Groups and Web Apps with ease. It details the setup process, which involves creating an Azure account, setting up environments, lifecycles, script modules, and variable sets, and explains the deployment and teardown processes using Azure PowerShell scripts. The post also covers advanced topics like using tenants for scalable deployments and leveraging Azure Resource Manager templates for multi-region deployments, alongside the introduction of Auto Deployment Triggers for automated deployments. Additionally, the guide highlights the potential for future enhancements in dynamic targets, hinting at upcoming features and improvements.

Mark Siedle's blog post discusses the integration of Azure Service Fabric Cluster targets with Octopus Deploy, highlighting the ease of setting up and deploying to Service Fabric clusters on Azure. With the impending retirement of Azure's Service Management API and the push towards Resource Management, Service Fabric is recommended for new cloud service development. The post provides insights into creating a Service Fabric cluster via the Azure portal and addresses common challenges such as the initial wait time for cluster readiness. It explains the packaging process for Service Fabric applications to ensure compatibility with real-world deployment pipelines, emphasizing the importance of the Service Fabric SDK and PowerShell script execution. The post also details the process of creating an Octopus Service Fabric Cluster Target, which allows for seamless communication and deployment to the Azure cluster, and it underscores the benefits of the new Azure Targets in simplifying the separation between infrastructure and deployment processes.

In May 2018, Octopus Deploy released version 2018.5, which enhances its Azure support by incorporating the latest Azure SDK and PowerShell Modules, and introduces dynamic management of Azure deployment targets using PowerShell Cmdlets. This update reintroduces Azure Web Apps and Azure Cloud Services as deployment targets and adds Azure Service Fabric Clusters, improving infrastructure visibility and enabling multi-region deployments. The release also features dynamic creation of PaaS targets, the ability to set Azure Accounts as variables, improved support for PEM certificate chains, and updates to licensing, where Azure targets now contribute to licensing limits. Notably, the update requires a minimum environment of Microsoft .NET 4.5.2 and PowerShell 5.0, and users are urged to switch from the soon-to-be-retired Service Management API to Service Principals for Azure accounts.

In this episode of "Will it Deploy?", the focus is on automating the deployment of an ASP.NET Core 2.0 web application to an Amazon Web Services (AWS) Ubuntu Linux Virtual Machine (VM) using SQL Server for Linux, with the help of Octopus Deploy and AppVeyor. The project involves deploying a simple random quote generator web app, showcasing the integration of a cloud-based delivery pipeline. The process includes committing source code to GitHub, building the application automatically with AppVeyor, and deploying it to an AWS Ubuntu VM using Octopus Deploy, which also manages the execution of database migration scripts with Entity Framework Core. The episode highlights the seamless integration between AppVeyor and Octopus, using custom build scripts and specific deployment steps, and invites viewers to engage with future episodes on their YouTube channel.

Octopus Deploy is introducing improvements to its team configuration system to simplify the management of user roles and permissions, which previously required creating multiple teams with the same members to apply different permissions across various environments. The current system's complexity often results in administrative overhead and confusion for users who need to configure teams according to specific project and environment requirements. The new approach focuses on making team members the centerpiece of configuration, allowing a single team to hold multiple roles and scopes, thereby reducing redundancy and administrative burden. This change, however, necessitates a breaking change in the API, requiring users to update their code to accommodate the new team data structure that supports linking multiple roles with their respective scopes. The overarching aim is to ensure users effortlessly achieve their desired configurations while minimizing complexity and potential errors.

Octopus was initially developed for small teams, with all elements like Projects, Environments, and Variable Sets existing at a global level, which posed challenges as larger organizations onboarded more teams. To address these issues, Octopus introduced the Spaces feature, allowing for better segregation within the platform by organizing almost everything into Spaces, while certain elements like Octopus Server Configuration, Users, and Teams remain global. This feature is optional, so users who do not require partitioning can continue using Octopus as before, but it offers a scalable solution for those experiencing growth and needing segregation. Some changes, particularly to the Teams management API, accompany this feature, and further technical details will be shared in a blog series to assist users in navigating these updates.