July 2026 Summaries

Matthew Casperson's article discusses the impact of AI on software development, particularly highlighting the surge in code commits, with GitHub reporting 275 million commits per week in 2026. The article emphasizes the challenge of aligning deployment frequency with commit frequency to ensure that only low-risk changes are deployed swiftly. It introduces the Run Claude Agent step in Octopus, which utilizes AI to automatically assess the risk of commits by analyzing their content and categorizing them based on impact factors like security and performance. By linking Build Information with deployment changes, Octopus can automate the decision-making process, triggering manual intervention only when high-risk changes are detected. The article provides a practical guide for creating a project that leverages this AI-driven capability, demonstrating the process with examples of both low-risk and high-risk commits, and outlines the steps for automatically or manually proceeding with deployments based on risk assessments.

In the guide, Jubril Oyetunji addresses the challenges of promoting applications to production using vanilla Argo CD, where promoting is merely editing a YAML file without any formal release management or audit trail. By integrating Argo CD with Octopus Deploy, the process transforms into a governed release management system that uses an immutable snapshot to move applications from Development to Production under policy and approval, thus ensuring accountability and traceability. The setup involves using Octopus Deploy to manage the lifecycle and promotion process, while Argo CD continues to sync the Kubernetes cluster with Git. This integration addresses issues such as lack of codified relationships between environments and fragmented promotion trails, offering a more controlled and auditable deployment process that captures who promoted what and when, with a single, consistent governance model across environments. The guide provides a detailed walkthrough on setting up and using these tools to achieve a more reliable and transparent deployment system, ultimately enhancing the governance and visibility of GitOps deployments.

In an episode of "Inside Platform Engineering," Matt Allford and Joep Piscaer discuss the challenges of navigating the Cloud Native Computing Foundation (CNCF) landscape, emphasizing that sometimes the best decision is to avoid adding unnecessary tools to a platform. Piscaer likens the CNCF landscape to a candy shop, warning that each tool added must be operated and supported, which can become burdensome over time. He suggests that small platform teams, ideally under eight members, are more efficient as they focus on essentials rather than expanding unnecessarily. Piscaer also highlights the importance of understanding the actual needs of users before building solutions, advocating for developers to spend more time in user engagement than coding. Additionally, the rise of AI-assisted coding is enabling business users to create their own tools, challenging platform teams to support these developments while maintaining simplicity and security. This shift may pose both a threat and an opportunity, depending on a platform's readiness to adapt to user-driven innovations.

Multi-tenancy, a concept tracing back to machine sharing, has evolved significantly with advancements in SaaS and lightweight virtualization, focusing on reducing complexity and improving resource allocation. Traditionally, multi-tenancy involved shared application instances and databases among multiple tenants, but this approach often led to complexities and risks, like data leakage and service disruption. Modern practices favor allocating dedicated instances to each tenant, enhancing data isolation, and simplifying resource management, making it easier to charge based on actual usage. Continuous Delivery (CD) tools now play a crucial role in this transformation by facilitating the deployment of multiple instances with tenant-specific configurations, effectively shifting multi-tenancy management from code to deployment pipelines. This adaptation allows tenants to be not only customers but also physical locations needing dedicated instances, ensuring high resource utilization without impacting others. The evolution of multi-tenancy is discussed by industry experts in the Continuous Delivery Office Hours series, offering insights and resources for further exploration.

Steve Fenton's article challenges the notion that AI has shifted the bottleneck in software delivery from coding to code review, arguing that neither has ever been the true constraint. Instead, Fenton suggests that deeply ingrained industry practices and the failure to identify and manage the actual bottlenecks in the value stream are the real issues. He emphasizes that focusing solely on speeding up coding or code review overlooks the broader context of delivering valuable software. The majority of teams deploy changes in batches, which indicates underlying constraints such as manual verification steps or cumbersome approval processes, rather than issues with coding or code review itself. Fenton advises organizations to identify and address these true constraints to optimize their value streams and achieve meaningful improvements in software delivery.

In a detailed exploration of deploying updates to an Argo CD Manifest file using Octopus, the text explains the process of creating a project that simulates updating these manifests without an actual Kubernetes cluster, utilizing a mocked environment. It outlines the prerequisites, including an Octopus Cloud account and AI Assistant Chrome extension, and describes the creation of a Git connection and a mock Argo CD Instance to facilitate the process. The Argo CD Manifest Update project is set up with specific Git credentials and repository settings, allowing Octopus to commit template files containing environment-specific configurations during deployment. The use of binding syntax in the template files enables dynamic configuration adjustments as deployments progress through different environments, although the demonstration operates entirely within a mocked setup, highlighting the flexibility and adaptability of the Octopus tool in managing GitOps workflows.

Paul Stovell discusses the challenges of integrating AI into software development, emphasizing that while AI can increase the speed of code generation, it often exacerbates compliance and risk management issues in large, regulated enterprises. He argues that the real bottleneck is not the speed of writing code but managing the risk associated with deploying changes. Stovell uses the metaphor of physics to describe how increased productivity often leads to an equal and opposite reaction from compliance functions, resulting in new processes that nullify productivity gains. He points out that compliance measures tend to accumulate over time, creating a "compliance ratchet" that is difficult to reverse. Stovell suggests a balanced approach where half of a team's efforts focus on accelerating change and the other half on ensuring those changes are safe and compliant. He believes AI can assist not only in generating code faster but also in assessing risks and improving compliance, ultimately maintaining customer trust, which is critical for business success.

Octopus has introduced Feature Flags, a new feature designed to enhance software deployment by allowing teams to control when and where new features are enabled without the need for redeployment. This functionality is built on OpenFeature, an open standard that offers a vendor-agnostic API for feature flagging, which allows for easy integration with various management tools and minimizes vendor lock-in. Octopus Feature Flags are deeply integrated with existing Octopus functionalities and support environment targeting, tenant and client rollouts, and context-driven segments to enable a controlled and customizable release process. Available as a public preview for Octopus Cloud customers, these feature flags have already shown success in improving the ability to release progressively and rollback instantly, ultimately contributing to a more stable product deployment. The system supports multiple programming languages and offers flexible options for developers, promising to expand availability to self-hosted Octopus Server customers in the future.

Octopus Deploy has transitioned target tags to a new management system using tag sets, allowing users to create, edit, and delete tags, thus improving tag maintenance and flexibility. This change retains the original functionality of target tags for filtering deployments and scoping steps to specific targets but enhances them with the ability to rename tags and use SingleSelect or MultiSelect tag set types to enforce data integrity. The new system also facilitates better organization by allowing tags to be divided into different sets and provides specific use cases, such as deploying to particular tags or excluding certain tags to ensure optimal deployment strategies. Existing users will find their target tags already migrated to a 'Default Target Tags' set, and the platform encourages thoughtful planning of tag dimensions such as role, cloud provider, and compliance scope for new setups. Guidance on designing tag sets and deploying strategies is available in their documentation.

Octopus Deploy is a deployment orchestration tool designed for enterprise environments, supporting multiple clouds and toolchains, and offering both a self-hosted version and a managed Octopus Cloud option. The importance of staying current with updates is emphasized, as they include essential security patches, bug fixes, performance improvements, and new features that help maintain compliance and reduce risk. Octopus Cloud users benefit from an automatic update process that keeps their instances up to date with the latest improvements, while self-hosted users are encouraged to regularly install updates to ensure optimal performance and security. Compatibility with popular software tools and the ability to integrate new functionalities are also highlighted, alongside the company's commitment to customer feedback and continuous product enhancement. Users are invited to explore new features and enhancements through the public roadmap and blog updates, ensuring they maximize the benefits of Octopus Deploy's evolving capabilities.

John Bristowe highlights the evolving role of code reviews in the era of AI-generated code, comparing it to a scene from "I Love Lucy" where Lucy and Ethel struggle to keep up with an accelerating chocolate assembly line. He argues that while AI has increased the speed of code production, it has also made thorough code reviews more challenging and less effective as quality assurance tools. Bristowe suggests that rather than relying solely on human reviewers, the industry should focus on improving deployment pipelines with automated checks and policy-as-code approaches to ensure software quality before it reaches production. He emphasizes that while code reviews are valuable for knowledge sharing and mentorship, they are not sufficient as the primary method for catching all bugs in AI-generated code. With AI becoming increasingly integral to development processes, Bristowe underscores the need for a robust pipeline that can verify code quality regardless of its origin, urging a shift from traditional code review practices to more automated and scalable solutions.

Matthew Casperson outlines a process for creating Ephemeral Environments using a sample Kubernetes project, focusing on deploying feature branches and facilitating development workflows before integration into the mainline branch. The project utilizes an Octopus Cloud account, an Octopus AI Assistant Chrome extension, and a mock Kubernetes server to simulate deployments. A key feature is the "Features" channel, which enables the deployment to ephemeral environments by creating a separate namespace for resources, distinct from traditional environments like Development, Test, and Production. The deployment process involves using a Kubernetes target linked to the Features environment, along with two runbooks for provisioning and deprovisioning ephemeral environments. These runbooks, executed from the "Hosted Ubuntu" worker pool, automate environment management, ensuring efficient resource handling.

Organizations often introduce heavy change approval processes in response to major incidents, aiming to stabilize operations during critical periods, such as seasonal sales or financial year-end. However, these cumbersome processes can ironically lead to greater instability by delaying work and causing a backlog of unreleased changes, complicating testing, and increasing the likelihood of merge conflicts. Instead of relying on centralized change approval boards, streamlining these processes through automation and peer-review for individual changes can enhance stability and efficiency. Automating verification tasks, like code linting and automated testing, reduces the need for manual intervention, while categorizing changes by risk ensures human oversight is applied where most needed. The Continuous Delivery Office Hours series emphasizes adopting small batch processing to mitigate problems associated with large batches, advocating for continuous improvement in software delivery practices.

Interest in AI agents continues to grow among large enterprises, with many companies appointing C-level executives to oversee AI implementation, signaling the significance and investment in this technology. The text explores the concept of sandboxing AI agents, which is crucial for improving security, especially for local AI agents that operate in users' workspaces and have broad access to systems and networks. Local agents, acting as general-purpose assistants, benefit from sandboxing to limit their extensive capabilities, whereas shared AI agents, designed for specific tasks, rely on pre-existing security measures. The discussion emphasizes distinguishing between local and shared agents and suggests that while sandboxing is vital for local agents due to their wide-ranging operations, shared agents, often running as web services, already employ robust security practices. Enterprises should focus on securing the tools used by shared agents rather than getting distracted by the notion of sandboxes, as existing security protocols for web services effectively serve the same purpose.