August 2021 Summaries

In 2021, Octopus Deploy transitioned its API framework from the outdated NancyFx to ASP.NET controllers to standardize and streamline its API development process. This decision addressed the confusion caused by a custom layer built on NancyFx and capitalized on the broader developer familiarity with ASP.NET. The migration process involved a strategic plan dubbed Derisk, Enable, Finish, which allowed both frameworks to coexist temporarily, facilitating a gradual transition. Initial tests showed improved performance with ASP.NET, and the team, consisting of four engineers, spent six months migrating 40% of the API endpoints. The migration strategy focused on derisking by analyzing, testing, and verifying endpoints, enabling by targeting less complex endpoints, and finishing by leveraging developer domain knowledge to continue migrations during routine changes. The process emphasized the importance of documentation, celebrating milestones, and collaborative efforts among the engineering team, acknowledging the complexity and repetitive nature of the task while highlighting the significant time investment required for such an undertaking.

Paul Stovell, the founder and CEO of Octopus, highlights the significant improvements in customer service that the company has achieved over recent years. Initially, Octopus focused on building a great product backed by excellent customer support, but only 20% of support inquiries received a reply within two hours due to the team being based solely in Australia. In response, the company expanded its support team to 17 full-time employees across the US and UK, significantly improving response times, with a 63% chance of replies within one hour and a 90% chance within two hours. The solutions team, consisting of seven senior engineers, specializes in integrating Octopus with other CI/CD tools and provides custom integrations through deep API use. Additionally, a sales and sales engineering team, which grew in 2020, focuses on product fit and customer success without commission incentives, ensuring a no-pressure sales environment. Stovell encourages customers to reach out for support, asserting that the enhanced customer service is as noteworthy as the product itself.

Octopus Deploy introduced the concept of Workers to manage increasing demands on its server by offloading tasks that do not execute directly on deployment targets. A Worker, essentially running the Tentacle software, is part of Worker Pools and does not count as a target under licensing rules, allowing unlimited usage. Workers are utilized for tasks such as database deployments, API calls, running scripts, and Kubernetes deployments, thus relieving the Octopus Server from long-running processes and enabling the use of custom software. Worker Pools provide flexibility with options to select different pools for various environments, and Workers can handle multiple tasks concurrently, contrasting with target machines that execute sequentially to prevent resource conflicts. Worker selection is managed in a round-robin fashion, with factors like package references and manual interventions potentially influencing the assignment. In Octopus Cloud, Dynamic Workers, available on demand, further enhance deployment capabilities by providing temporary resources for cloud instances.

In a recent webinar, Chris Thomas from Clear Measure and Derek Campbell discussed optimizing Octopus Deploy for enhanced performance and user experience by focusing on database maintenance and organizational strategies. Chris emphasized the importance of managing the SQL database that runs Octopus Server, suggesting tools like Microsoft SQL Server Management Studio for tasks such as checking index statistics, defragmenting databases, and setting up a maintenance plan using the SQL Server Maintenance Plan Wizard. Additionally, the webinar highlighted the benefits of organizing Octopus Deploy environments and projects efficiently to improve performance and dashboard navigation. Recommendations included limiting environments to those necessary for the development pipeline, using project groups to reduce visual clutter, leveraging Tenants for organizing various facets of deployment, and implementing Lifecycle retention policies to manage old releases and builds effectively. These strategies aim to streamline Octopus Deploy operations, ensuring smoother deployments and better resource management.

Shawn Sesna's article from August 16, 2021, provides a comprehensive guide on how to generate and upload build information to Octopus Deploy using GitLab as the build server. The process begins with creating necessary variables, such as a GitLab Personal Access Token and Octopus Deploy API Key, to facilitate API calls for gathering commit information. The tutorial focuses on constructing a build information file using PowerShell within GitLab's Docker runner and outlines the YAML configuration needed for defining the build stages. The build process is split into two main stages: "build-information" to gather and store the build data in a JSON file, and "push-build-information" to upload this data to Octopus Deploy using the Octopus CLI. Sesna emphasizes the importance of securely managing access tokens and concludes by demonstrating the successful transfer of build information to Octopus Deploy, encouraging readers to leverage these practices for efficient cloud deployments.

Octopus is enhancing its integration with Amazon Elastic Container Service (ECS) by developing a second milestone that introduces a new step to update existing ECS services with new image versions, without taking over the creation of these services. This development aims to address feedback from teams already managing ECS resources, who found updating services with new images in their CI/CD pipelines challenging. The proposed step will create a new task definition revision with an updated image tag and update the service while linking to existing load balancers, allowing for image deployments to established ECS clusters while maintaining control over existing infrastructure. Although milestone two focuses on supporting established ECS clusters, it retains limitations from the first milestone, such as deploying only to Fargate, supporting only rolling deployments, and excluding auto-scaling and other settings. Feedback is sought to refine this feature, with the work on milestone two scheduled to begin after the completion of milestone one, though no release date has been announced yet.

Google Cloud Functions (GCF) is a Function as a Service (FaaS) platform that enables the execution of applications in response to events from external sources like HTTP requests or other Google Cloud Platform services. Supporting multiple programming languages, GCF typically requires raw source code upload, except for Java applications which can be deployed using JAR files. The platform simplifies deployment by handling dependencies and code compilation, as demonstrated in the example of a Java API for a Random Quotes web app. While GCF facilitates straightforward deployments, it lacks advanced versioning and networking capabilities found in other GCP services, necessitating external orchestration for complex deployment strategies. Despite this, the simplicity of GCF is advantageous for traditional deployments, as it reduces the effort required from developers, who can rely on Google to manage the compilation process.

Google App Engine (GAE), part of the Google Cloud Platform, is a Platform as a Service (PaaS) that supports web applications across various programming languages, offering features such as network routing, job scheduling, persistent data storage, and task queues. This post demonstrates deploying a Java Spring web application, Random Quotes, using GAE. It explains the process of creating an application resource within a Google Cloud project and deploying the application using a compiled JAR file, a feature unique to Java on GAE. The article also covers setting up and deploying feature branches, using configuration files like app.yaml and dispatch.yaml to define services and traffic routing rules. Additionally, it illustrates advanced deployment scenarios such as canary and blue/green deployments through traffic splitting, allowing for gradual traffic direction between different application versions. The flexibility of GAE in handling complex deployment patterns is emphasized, showcasing its suitability for sophisticated web application management.

The blog post by Egor Pavlikhin explains how to integrate Terraform Cloud with Octopus Deploy to manage infrastructure efficiently using version-controlled templates from a GitHub repository. It details the process of setting up a Terraform workspace on Terraform Cloud, highlighting the importance of specifying the correct Terraform version to avoid incompatible state formats. The post guides users through creating a GitHub repository as a package feed for Octopus Deploy, structuring Terraform files, and configuring variables for secure storage and integration with AWS. It emphasizes the use of Terraform's remote back-end to keep track of workspace states and enable collaborative management of infrastructure. Additionally, the article outlines the steps to create a runbook in Octopus Deploy, demonstrating how to apply a Terraform template and manage infrastructure deployment seamlessly.

Google Cloud Run is a Platform as a Service (PaaS) on the Google Cloud Platform that allows users to run and scale container images, charging only for the time a request is processed. The text explains deploying a sample Java Spring web application called Random Quotes using Cloud Run, starting with pushing a Docker image to the Google Container Registry (GCR). It highlights the use of service YAML resources in defining services and deploying them with Google Cloud commands. The discussion includes strategies for feature branch deployments and implementing canary and blue/green deployments through service revisions and traffic management, using tools like skopeo for image copying and assigning tags for testing new revisions. The platform offers automatic scaling and traffic routing, supporting DevOps practices in application deployment.