September 2026 Summaries

Matthew Casperson describes creating an Octopus project that deploys and progressively promotes Argo CD Rollouts on Kubernetes, demonstrating blue-green, canary, experimentation, and progressive-delivery capabilities. Using the Octopus AI Assistant, users configure a mock token account, Docker Hub feed, Kubernetes target, Git connection, and a Progressive lifecycle spanning Development, Prod 10, Prod 50, and Prod 100 environments. The rollout manifest uses Octopus template syntax to send all development traffic immediately to a new application revision, while production begins at 10% traffic and pauses for approval before promotion to 50% and then 100% through kubectl Argo Rollouts commands. New releases select updated container image tags, creating new rollout revisions, and the Octopus dashboard displays progress across environments. Suggested production enhancements include adding integration or end-to-end tests and automatically aborting rollouts if those tests fail.

Octopus Approvals is a lightweight deployment-gating feature designed for organizations that need stronger controls than manual intervention steps provide but do not require a full ITSM change-management platform such as ServiceNow or Jira Service Management. Available in public preview for Octopus Cloud customers and in the 2026.3 Server release, it requires designated team members to approve deployments before they begin in selected environments, with configurable rules for approval counts, teams, project and environment tags, and restrictions preventing deployment creators from approving their own changes. Rules operate at the space level and can cover multiple projects, while approved releases can be redeployed to the same environment without renewed approval to support rollbacks. Rejections fail the deployment and require a new deployment request, while audit logs, approval history, and subscriptions for email, Slack, Teams, or webhooks provide visibility and notifications. Current limitations include shared approval counts across specified teams, no automated approvals, and support only for deployments rather than runbooks.

In an Inside Platform Engineering discussion, Kian Rogerdi argues that platform teams should judge their work by the business value and developer outcomes they enable rather than technical sophistication alone. Drawing on more than 20 years in software leadership across cloud engineering, SRE, and platform engineering, he emphasizes that internal development teams should be treated as customers whose needs must be actively understood through observation, feedback, and close collaboration. Platform engineers can reduce cognitive load for stream-aligned teams by embedding with them, identifying why official templates or pipelines are bypassed, and adapting services to solve real problems. Rogerdi also warns against platform teams becoming gatekeepers that use standards or technical authority to control other teams, while recognizing that genuine regulatory and compliance requirements remain necessary in sectors such as healthcare and fintech. The discussion presents a customer-focused, enabling mindset as essential for keeping platform engineering aligned with its purpose of helping teams deliver software faster and more safely.

Steve Fenton argues that using AI to accelerate software development without strengthening delivery practices can trigger a “compliance ratchet,” in which outages or serious bugs lead organizations to impose restrictive controls that are difficult to remove and may erase AI-driven productivity gains. He advises teams to balance AI investment across the full software delivery flow rather than merely increasing coding output, since downstream review, approval, deployment, and feedback bottlenecks can absorb added volume. Organizations should reassess accumulated controls, many created after past failures, and replace slow manual checks with automated, repeatable validation where possible to improve both speed and stability. Fenton concludes that successful delivery depends not only on velocity but also on direction: frequent releases can help teams learn what users need, while robust technical practices are increasingly necessary to deliver reliable software at modern scale.

Continuous Integration requires developers to merge changes into a shared main branch frequently, ideally more often than daily, rather than relying on long-lived branches or merely running automated builds and tests. Continuous Delivery builds on CI by keeping software deployable at all times through an automated deployment pipeline that provides confidence in each version’s readiness, though actual releases may be manual or automatic; automatic releases are specifically Continuous Deployment. The discussion argues that CI is an essential prerequisite for CD, citing foundational work by Kent Beck, Dave Farley, and Jez Humble, and rejects claims that CI/CD is inherently vague or compatible with feature branches that remain separate from main for extended periods. It warns that redefining these terms to omit their core practices risks losing established engineering knowledge, similarly to perceived dilution of concepts such as Agile and DevOps.

Matthew Casperson’s post demonstrates how Octopus Cloud runbooks can be triggered externally through webhooks to automate ad-hoc and maintenance tasks. Using the Octopus AI Assistant Chrome extension, users create a Script project named “23. Script App with Runbook Webhooks,” add a runbook containing a script that logs “Runbook triggered by webhook,” and configure a webhook trigger for it. Because the AI Assistant does not accept or retain supplied secrets, it automatically generates a webhook secret that users must replace with their own value, while Octopus API keys can also authenticate webhook calls. The resulting webhook endpoint can be invoked with a POST request, including the webhook secret in the X-Octopus-Webhook-Secret header, to execute the runbook.