March 2022 Summaries

The article delves into the architectural evolution of the Octopus Deploy platform, particularly focusing on the transition from SQL to a more abstract document store approach to support the Configuration as Code feature. Initially, Octopus relied on SQL for data persistence, but as version control became integral, the need for a more flexible system emerged. The Core Platform team introduced a document store abstraction layer, enabling seamless interaction with both SQL and version-controlled projects via Git, without the API consumer needing to understand the underlying persistence mechanisms. This shift also led to the introduction of a Unit of Work pattern to simplify transaction management, allowing developers to focus on their tasks without being burdened by transactionality or caching concerns. Enhanced by a strategy pattern, the system automatically determines the appropriate data store type, and project scope encapsulates project and branch information, reducing the need for extensive parameter passing. This architectural refinement aims to streamline development processes, encourage best practices, and ensure a scalable, intuitive experience for both developers and end-users.

The Octopus 2022 Q1 release introduces several significant updates, most notably the general availability of Configuration as Code (Config as Code) for deployments, allowing users to create version-controlled projects that integrate seamlessly with Git, enhancing traceability and collaboration. This release also features a Visual Studio Code extension with Octopus Configuration Language (OCL) support, an updated Terraform Provider, and new integrations, including Buildkite plugins for pipeline automation and Opsera for no-code DevOps orchestration. Additionally, Octopus now supports multiple Azure DevOps organizations and includes enhancements to the TeamCity plugin and the next-generation step package framework for automated step updates. The acquisition of Dist suggests future developments in container registry capabilities. Overall, the release emphasizes improved deployment processes, integration capabilities, and user feedback-driven enhancements, marking a significant step forward in Octopus's commitment to Config as Code.

Michael Richardson, Director of Product at Octopus, shares insights into his role and the evolution of the company. With a background in software engineering and leadership, Richardson emphasizes the challenges of prioritizing product development amidst Octopus's growth from 10 to nearly 200 employees. His role focuses on expanding Octopus's capabilities and integrating new technologies to enhance user experience. Current projects include implementing Config as Code for version control in Git, developing dynamic environments for on-demand test setups, and integrating with ITSM tools like ServiceNow. Richardson measures success by how effectively Octopus helps customers deploy software reliably and frequently, contributing to their value delivery. He reflects on the industry's shift towards automation, feeling proud of Octopus's role in that transition and its growth as an Australian company.

Octopus Deploy has introduced a new feature called Configuration as Code (Config as Code), which allows Octopus project configurations to be stored in a Git repository instead of a relational database, enhancing version control, branching, and collaboration. This feature aims to provide a solution to the highly requested ability for version-controlling Octopus configurations, offering benefits like viewing historical changes, enabling multiple deployment process versions through Git branches, and maintaining a single source of truth by having application code and deployment configuration together. The development team avoided certain anti-patterns found in similar integrations, such as treating Git as just another database or abstracting Git concepts too heavily. Instead, they designed the feature to leverage Git's capabilities, such as branches and commit messages, while maintaining Octopus's usability. The configuration language chosen is based on Hashicorp's HCL, referred to as Octopus Configuration Language (OCL), for its readability and suitability for complex deployment processes. After an early access preview in 2021, Config as Code is set to be available for production use, with webinars offered to guide users in adopting and scaling this feature.

John Bristowe discusses the integration of Octopus Deploy with Opsera's no-code DevOps orchestration platform, which supports over 95 platforms. This partnership allows users to automate their CI/CD pipelines through a visual interface, enabling the creation of declarative pipelines with unified insights. By leveraging Opsera's integration, users can access resources defined in Octopus Deploy, such as channels, environments, and projects, by first creating an API key in Octopus and registering it in Opsera's Tool Registry. Opsera's platform offers a powerful visualization and orchestration of pipeline workflows, allowing for customization and consistent experiences across supported platforms. This integration simplifies the automation of deployment processes, making it accessible for users to incorporate Octopus Deploy into their existing workflows.

Sarah Lean shares her learning journey with Octopus Deploy, emphasizing its integration capabilities and features as part of a blog series. She highlights the Config as Code feature, which allows version control of deployment processes by integrating with Git, providing a single source of truth for application code, build scripts, and deployment configurations. Lean also explores the export and import functionality, enabling users to transfer projects between spaces for better organization and visibility, although with some limitations on what can be exported. Additionally, she discusses Octopus Deploy’s compatibility with various authentication systems like Active Directory and GitHub, aiming to provide a seamless user experience without additional login credentials. Personalization of spaces through descriptions and logos is encouraged to enhance identification and collaboration. Lean concludes by expressing her growing comfort with Octopus Deploy, inviting further engagement from readers.

GitHub provides a secure way to manage sensitive data, known as secrets, which are encrypted and hidden yet accessible for use in projects, particularly within GitHub Actions workflows. Secrets can be stored at three levels: repository, environment, and organization, each with specific access permissions and limitations, such as a maximum of 100 secrets per repository or environment. Users can add and update secrets through the GitHub interface, ensuring that sensitive information such as API keys remains protected while allowing seamless integration and deployment processes, such as connecting workflows with services like Octopus Deploy. It's essential to handle secrets securely by avoiding their inclusion in log files and using the secrets context to call them within workflows. For more detailed information on managing secrets and integrating them into GitHub Actions, users are encouraged to consult GitHub's documentation and explore additional resources available in the Continuous Integration series.