January 2020 Summaries

Octopus Operations Runbooks integrate seamlessly into the DevOps landscape by automating routine maintenance and emergency operations tasks, enhancing both efficiency and reliability. Released for Octopus Cloud and self-hosted customers using version 2019.11.0 or newer, these runbooks replace traditional IT process documents with automated workflows that minimize human error and expedite incident resolution. By leveraging existing infrastructure and providing comprehensive security, permissions, and auditing features, Octopus enables teams to manage, execute, and schedule tasks without additional configuration. This centralized approach not only improves discoverability and visibility but also allows for better control and faster incident response, with examples including database administration and web service recovery. Through automation, Octopus fosters trust between developer and operations teams while reducing the friction traditionally associated with operations management.

Octopus is introducing a significant update to its library variable sets, allowing for more granular control over permissions with the decoupling of LibraryVariableSetView and LibraryVariableSetEdit from the EnvironmentView permission in the 2020.1.2 server version. Previously, these permissions were tied to EnvironmentView, limiting users' ability to manage variables across environments and tenants. The change enables users to scope library variable set permissions independently, which enhances the flexibility and capability of managing access to variables. However, this update represents a breaking change, potentially affecting users who have automated permission configurations, particularly those with custom roles lacking EnvironmentView. Octopus has communicated with customers to ensure they adapt to this change, and migration adjustments will occur during server startup to preserve current access levels. Users are encouraged to verify their configurations and contact Octopus Support if they have questions or concerns about the impact of this update.

In his blog post, Shawn Sesna provides a comprehensive guide to building and deploying a Java-based web application with a MySQL backend using Azure DevOps and Octopus Deploy. The tutorial details the setup process, including the configuration of Java Development Kit (JDK) and Maven on a build agent, and the modification of the Maven Project Object Model (POM) file to support dynamic versioning and MySQL. Sesna also introduces Flyway, a migration-based database deployment tool, to manage SQL scripts and database changes. The guide walks through setting up Azure DevOps to package and push the application to Octopus Deploy, where it is further configured for deployment on web servers like Wildfly. Throughout the process, Sesna emphasizes the use of environment-specific variables and best practices in configuration to streamline CI/CD workflows and ensure successful deployment across various environments.

KIND, short for Kubernetes IN Docker, offers a novel approach for creating local test Kubernetes environments by using Docker to host the nodes, providing a self-contained and easily manageable solution. This method simplifies the process of setting up and tearing down Kubernetes clusters, making it particularly useful for developers and administrators. Installation requires Docker and Go, and clusters are quickly created and managed through a few simple commands, with the first setup being slightly longer due to image downloads. Accessing services within KIND requires additional steps, such as using kubectl as a proxy or port forwarding, to expose the necessary endpoints. Despite the initial challenge of accessing services, KIND performs well for a beta release, supporting external tools like Helm and allowing for the deployment of custom dashboards. It stands out for its convenience and potential integration into automated testing workflows, offering a compelling alternative to existing solutions like minikube for local Kubernetes testing.

Shawn Sesna's blog post provides a detailed guide on integrating Docker containers and Kubernetes into a Continuous Integration and Continuous Delivery (CI/CD) pipeline using a real-world application called OctoPetShop. The post explains the process of setting up a Kubernetes cluster, creating and managing YAML files for different services, and implementing a CI/CD pipeline with TeamCity as the build server and Octopus Deploy for deployment. It highlights the importance of versioning YAML files and replacing sensitive information with variables for security. Additionally, the post introduces an alternative method for deploying to Kubernetes using Octopus Deploy's form-based approach, which bypasses the need for writing YAML and skips the CI portion, focusing solely on CD. This method allows users to define Kubernetes clusters dynamically during deployment, ensuring compatibility with the Kubernetes API version used.

Octopus Deploy 2019.12 LTS introduces various enhancements and features aimed at improving automation and deployment processes for self-hosted Octopus Deploy users, with a focus on long-term support including critical bug fixes and security patches. Key features include the introduction of Operations Runbooks for automating routine tasks, an official Jenkins plugin for better integration with CI/CD pipelines, and PowerShell Core support for cross-platform scripting. The release also enhances build information management by promoting it to a top-level feature, making it more accessible, and introduces several user-driven improvements such as simpler package-based step templates and improved dashboard configuration. Notably, the release includes breaking changes related to PowerShell Core execution and build information resource renaming, necessitating upgrades for those using certain plugins or integrations.

Shawn Sesna's blog post from January 2020 explores the use of Docker containers and Kubernetes in managing a real-world web application, specifically OctoPetShop. The post delves into Kubernetes as a container orchestration tool, explaining its architecture and the role of nodes and pods. It provides a practical guide on setting up Kubernetes components like deployments and services for OctoPetShop, including the use of YAML files to define resources and enable pod communication. The post highlights the importance of services such as ClusterIP and LoadBalancer for internal and external communication, respectively, and discusses the use of Kubernetes Jobs for terminating tasks like database seeding. The author also shares insights on using kubectl for managing and troubleshooting Kubernetes deployments, emphasizing that while Kubernetes may seem complex, running applications on it can be straightforward with the right setup and resources. The OctoPetShop GitHub repository contains all necessary files for deploying the application using Docker, Docker Compose, and Kubernetes, demonstrating the potential of these technologies in DevOps environments.

Pipeline as Code (PaC) emerged as a developer-friendly technique that integrates the code being developed with the scripts needed to build and test it, perfectly aligning with developers' workflows. This method ensures that PaC logic and its short-lived infrastructure are synchronized with each code commit, making it well-suited for the build and test cycles owned by developers. However, extending PaC to include deployments introduces complexities due to longer deployment timelines and the involvement of multiple teams such as QA, security, and product management. The distinction between releases and deployments is crucial, as deployments involve broader collaboration and differing timelines, which often do not align with the developer-centric, short-term focus of PaC. Therefore, while PaC can effectively handle building and testing, it may not be suitable for managing the comprehensive and varied requirements of deployment processes, suggesting that these workflows might be better managed as separate entities.