Overview
CI/CD remains difficult because deployment safety depends on far more than automating builds: teams must reconcile infrastructure, application state, database evolution, organizational controls, and increasingly AI-generated code. Rob Ewaschuk traces a maturity path from direct production changes through continuous integration, continuous delivery, and continuous deployment, while emphasizing that not every organization should automate releases all the way to production. Kubernetes has become a common declarative control plane not only in public clouds but also in stores, private data centers, and even research vessels. GitOps extends that declarative model through versioned desired state, pull-based updates, and continuous reconciliation, but its principles do not require putting everything in Git. Progressive delivery reduces exposure through canaries, blue-green deployments, and especially feature toggles, which offer granular targeting and near-instant deactivation. The hardest recovery cases involve persistent state and schema migrations, making roll-forward fixes safer than simplistic rollback strategies. Platform teams can standardize delivery through self-service templates without removing operational ownership from application teams. Looking ahead, AI is expected to increase code volume, shift optimization away from pipeline speed alone, and increase the value of risk controls, automated validation, ephemeral environments, and feature flags.
Sections
Core Delivery Concepts
Terms used to distinguish deployment maturity and release-control techniques.
- Continuous integration means frequently merging changes into a shared branch and continually testing the integrated code.
- Continuous delivery means continually validating both the software and its deployment process so a production release can be triggered whenever desired.
- Continuous deployment means qualifying changes flow automatically into production without manual intervention.
- Progressive delivery releases changes through controlled exposure rather than sending a new version to all production users at once.
- A canary deployment runs a new version alongside the old one and gradually routes a selected subset of traffic to it.
- A feature toggle, also called a feature flag, selects between code paths through externally controlled state and separates feature release from software deployment.
- An ephemeral environment is a temporary, fully provisioned environment created for a branch or job and removed when the work is complete.
Implementation and Architecture Details
Concrete mechanics discussed for infrastructure reconciliation, progressive delivery, and hosted operations.
- Kubernetes controllers reconcile declared state with runtime state; if three replicas are requested and one pod dies, the system creates a replacement.
- GitOps uses declarative state, versioned and immutable references, pull-based application, and continuous reconciliation. A GitOps agent retrieves the desired state and applies it to Kubernetes, correcting later drift.
- Canary delivery commonly runs version one and version two together, uses a network traffic manager to send a small percentage of requests to version two, and changes that percentage according to observability signals.
- Octopus uses OpenFeature as its feature-toggle SDK and adds a wrapper containing the owning team and an expiry date so CI can notify teams about stale flags.
- Octopus SaaS evolved from one virtual machine per customer, costing about $100 per customer each month, to a Kubernetes-based cell architecture called a reef, where customer instances run in pods alongside associated resources such as an Azure database.
- On-premises upgrades propagate slowly: approximately 50% of customers adopt a release after 200 days on average, while 75% adoption takes more than 400 days.
Important Tradeoffs
Explicit contrasts between delivery models and operating environments.
- Continuous delivery keeps a release production-ready but permits manual approval; continuous deployment automatically sends qualifying changes to production.
- Canary delivery controls exposure at the application-version level, whereas feature toggles can control individual code paths and target users with more precise rules.
- SaaS permits centrally controlled, staged upgrades; self-hosting gives customers control but requires the vendor to support irregular and widely separated upgrade paths.
- A rollback restores an earlier version and may conflict with current state; a roll-forward response creates a new version containing the corrective change.
Operational Risks and Mitigations
Failure modes that can undermine otherwise mature delivery practices.
- Treating rollback as universally safe can leave old code running against an incompatible database schema or altered data.
- Putting secrets in Git because GitOps is interpreted as an everything-in-Git mandate creates avoidable credential exposure and lifecycle problems.
- Feature flags can accumulate throughout the codebase and create permanent branches, unclear ownership, and stale external configuration.
- Ephemeral environments become difficult when an application depends on many services, persistent state, or realistic datasets.
- Running thousands of independent GitOps-managed edge clusters can throttle or bottleneck the repository serving desired state.
Expected Direction of Software Delivery
Forecasts made or endorsed during the discussion.
- AI-assisted development will generate substantially more code and increase delivery velocity.
- Pipeline speed may receive less emphasis when agents can wait for tests, inspect failures, and issue fixes without blocking a human engineer.
- Progressive delivery and especially feature toggles will become more common as teams seek to constrain the risk of AI-generated changes.
- Self-hosted infrastructure software will remain relevant because banks, governments, and regulated institutions continue to require control over hosting, upgrades, and downtime.