Replacing running software with a new version is the riskiest routine thing a team does. The strategy you choose decides how many users a bad version can hurt, how long they are hurt, how much extra capacity you pay for, and how quickly you can undo it. A good strategy turns "we shipped and hoped" into "we shipped to 1 percent, watched the numbers, and promoted".

The first idea to internalise is the split between two events that most teams treat as one:

Every strategy in this page is a different answer to the same four questions. Keep them in mind as you read:

• Exposure: what fraction of users or requests meets the new version first?
• Capacity: do old and new versions run side by side, and does that need extra servers?
• Compatibility: can old and new versions run at the same time against the same database and the same messages? (Chapters 6 and 7: this is where most real outages come from.)
• Reversal: how long and how risky is it to go back?

This page builds on page 05 CI/CD Pipelines (the pipeline that triggers deployments), page 03 Kubernetes Core and page 04 Kubernetes Operations (the primitives), and page 07 Observability (the metrics that tell you whether a rollout is healthy).

Stop everything that runs the old version, then start the new version. It is the simplest strategy and the only honest one when two versions cannot coexist: a single-instance application, a schema change that breaks the old code, a licence that allows one instance. The price is downtime equal to shutdown plus startup plus warm-up. Kubernetes supports it as strategy.type: Recreate: all old pods are terminated before any new pod is created.

Replace instances gradually: start some new ones, wait until they are healthy, stop some old ones, repeat. No downtime and no extra environment, but for a while both versions serve traffic, so they must be compatible with each other and with the data. A rolling update has no built-in notion of "watch the error rate": its safety check is only the health probe.

A Kubernetes Deployment supports exactly two strategy.type values: RollingUpdate (the default) and Recreate. For RollingUpdate, two fields set the pace. Per the Kubernetes documentation both default to 25 percent, and each can be an absolute number or a percentage:

The /actuator/health/readiness path is the Spring Boot readiness probe group, available when probes are enabled (they are enabled automatically when Boot detects Kubernetes; management.endpoint.health.probes.enabled=true forces it). The preStop sleep gives the endpoints controller and load balancers time to stop sending new connections before the process gets SIGTERM, which is a standard fix for errors during rollouts.

Run two complete production-like environments: blue (the current version, serving users) and green (the new version, idle for users). Deploy to green, test it with real infrastructure and synthetic or internal traffic, then switch the router so green becomes live. Blue stays up for a while as the instant rollback target, then is retired or becomes the next green.

Named after the canary in the coal mine: send a small share of real traffic to the new version, compare its health with the old version, and only then increase the share. If metrics degrade, the share drops back to zero and only a few users noticed. The blast radius is chosen by you (1 percent, 5 percent) instead of by the size of the fleet.

• Errors: HTTP 5xx ratio of the canary against the baseline (page 07: RED metrics and the PromQL error ratio).
• Latency: p95/p99 of the canary against the baseline, from a histogram.
• Saturation: CPU, memory, GC pauses, connection pools of the canary pods.
• Business metrics: orders per minute, payment success, login rate. A version can be technically healthy and commercially broken.
• Enough samples: require a minimum request count per step, or a 1 percent canary at low traffic proves nothing.

In a shadow deployment real requests are copied to the new version, whose responses are discarded. Users only ever see the old version, so a bug in the new one hurts nobody, but the new version is exercised with genuine production traffic shapes. It is ideal for validating a rewrite, a new database engine or a performance change. Mirroring is supported by service meshes and gateways such as Istio, and Flagger documents blue/green mirroring for Istio and Gateway API.

A canary asks "is the new version healthy?" and routes by percentage of traffic. An A/B test asks "which version produces a better outcome?" (conversion, retention) and routes by user attributes or cohorts (a header, a cookie, a user id hash, a country), keeping each user on the same variant for the whole experiment. It needs statistical analysis, runs for days or weeks, and is owned by product as much as by engineering. The routing machinery overlaps with canaries (Flagger documents A/B testing on HTTP headers and cookies), but the goal and the success criteria differ.

A feature flag (feature toggle) is a runtime switch around a code path. The code ships to production disabled; a configuration change enables it for chosen users. That is the second half of the idea in chapter 1: deploy is a technical event, release is a decision that can be made later, per user group, and undone in seconds without a deployment.

A property that needs a restart to change is a deploy-time flag, which defeats the purpose. Dedicated flag systems (commercial products such as LaunchDarkly, open-source ones such as Unleash, or a homegrown service) evaluate flags at request time with user context, so you can enable a feature for employees, then 1 percent of users, then everyone. OpenFeature is a CNCF project that defines a vendor-neutral flag evaluation API, so application code does not depend on one vendor.

• Test both sides of the flag in CI.
• Make the default (when the flag service is unreachable) the safe one, and cache the last known values.
• A flag does not remove the need for compatible schemas: the flag is evaluated per request, so the code for both branches must work with the current database.
• Log or tag the flag state on traces and metrics so you can tell which variant caused an issue.

Application code is easy to replace and easy to roll back: it is stateless, and the old version is one kubectl rollout undo away. The database is not. It is shared by every running version, it is hard to undo, and during any rolling, canary or blue/green deploy two versions of the code run against one schema at the same time. So the schema must always be compatible with both the version being replaced and the version replacing it.

The technique is expand and contract, also called parallel change: make a breaking change in three compatible stages instead of one incompatible step.

I ran this sequence against an in-memory SQLite database: after V2 the new columns were NULL, after V3 they held Ada/Lovelace and Alan/Turing, and after V4 the old column was gone and the rows were intact. SQLite stands in only to check the statements; substr and instr are SQLite functions, so on PostgreSQL you would use split_part and similar, and other engines have their own string functions.

Both tools version the schema as code, apply pending changes in order at deploy time, and record what was applied in a table so each change runs exactly once.

During any gradual deploy, clients and servers of different versions talk to each other. A caller on v1 hits a server on v2, a v2 service calls a v1 service, a message written by v2 is read by a consumer still on v1. The rules for staying safe are old and consistent.

Follow the robustness principle in clients (be liberal in what you accept) and treat the contract as additive-only. Deploy order matters when a contract does change: for a new optional capability deploy the provider first, then the consumers; when removing, stop the consumers from using it first, then remove it from the provider.

Messages are harder than HTTP because they outlive the deployment: events written by v2 sit in a Kafka topic or queue and are read later, possibly by v1, possibly in a replay months later. Use a schema format with explicit evolution rules (Avro, Protobuf, JSON Schema with a registry) and check compatibility in the build. In schema-registry terms: backward compatible means new readers can read old data (add optional fields with defaults); forward compatible means old readers can read new data; full means both. When consumers are upgraded before producers, backward compatibility is enough; when producers may be upgraded first, forward compatibility is needed; when you cannot control the order, require full. See page 07 Event-Driven Patterns and page 08 Reliability & Operations in the Messaging section.

• Default to rollback for application changes: it is the fastest way to stop the bleeding, and with expand/contract it is always available until the contract step.
• Plan for roll-forward when data is involved: destructive migrations and one-way data conversions cannot be undone by redeploying code.
• Whichever you choose, decide before the rollout (the release checklist in chapter 9 asks for it) and rehearse it. Deciding under incident pressure is how mistakes happen.
• Keep the previous artefact and its configuration available, and keep build artefacts immutable: roll back to the same image digest you ran before, not "rebuild v1".

Progressive delivery automates canary and blue/green: a controller shifts traffic in steps, queries your metrics at each step, and promotes or aborts without a human watching. Two widely used Kubernetes controllers do this.

Read the steps top to bottom: send 10 percent of traffic to the new version, wait five minutes, run the analysis (five measurements one minute apart, tolerating at most one failure), then go to 50 percent, wait ten minutes, then 100 percent. If the analysis fails, the controller aborts and returns traffic to the stable version. The result[0] syntax is how Argo Rollouts reads the first element of a Prometheus vector result. The query is the same error-ratio pattern from page 07, parameterised to the application label. Without a traffic-routing integration Argo Rollouts approximates the weights using the ratio of canary to stable pods.

Flagger raises the canary weight by stepWeight every interval until maxWeight, checking the metrics each time; after threshold failed checks it rolls back. The thresholds above mean "success rate at least 99 percent, request duration at most 500" (Flagger documents the duration threshold in milliseconds for its built-in metric).

This table compares qualitative trade-offs and is not a benchmark: real cost and speed depend on your platform and tooling. Strategies combine well: a common mature setup is a rolling or canary deploy with the new code behind a feature flag, over an expand/contract schema, gated by SLO metrics.

• Automated smoke tests against the new version immediately: login, one read, one write, one dependency call.
• Watch the golden signals (page 07) for the new version for a defined bake time: error ratio, p95/p99 latency, saturation, and business KPIs, compared with the baseline.
• Check logs for new error signatures and exceptions that did not exist before; check traces for new slow spans.
• Confirm the deploy is real: an exposed build-info endpoint (/actuator/info with git commit) or a version metric proves which version answers.
• Verify dependencies: queue depth, consumer lag, database connection and slow-query metrics.
• Close the loop: only then promote, scale down the old version, and remove the flag or old environment.

Crisp answers for deployment-strategy questions.

• Q: Compare rolling, blue/green and canary deployments.
  Rolling replaces instances gradually using the same capacity but with no metric-based gate and mixed versions for a while. Blue/green runs a full second environment and flips traffic at once: fastest rollback, higher cost. Canary sends a small, growing share of traffic to the new version and promotes based on metrics: smallest blast radius, needs weighted routing and good observability.
• Q: What is the difference between deployment and release?
  Deploy puts new code into production; release exposes it to users. Feature flags and traffic routing let you separate them, so a risky feature can ship dark, be enabled gradually and be switched off in seconds.
• Q: How does a Kubernetes rolling update work, and which settings control it?
  The Deployment scales a new ReplicaSet up and the old one down, governed by maxSurge and maxUnavailable (both default to 25 percent), and new pods only count once their readiness probe passes (plus minReadySeconds). kubectl rollout undo returns to the previous ReplicaSet.
• Q: A rolling update caused errors for a few seconds even though the pods were healthy. Why?
  Typical causes: no or weak readiness probe, no graceful shutdown (in-flight requests dropped when SIGTERM arrives), load balancers still sending traffic to a terminating pod (fix with a preStop delay and server.shutdown=graceful), or too aggressive maxUnavailable.
• Q: What is expand and contract?
  A pattern for making breaking schema or API changes safely: expand by adding the new structure alongside the old, migrate by dual-writing, backfilling and switching reads, then contract by removing the old structure. Every step is compatible with the running version and the previous one, so rollbacks stay safe until the final destructive step.
• Q: How would you rename a database column with zero downtime?
  Add the new column (nullable); deploy code that writes both; backfill existing rows in batches; deploy code that reads the new column; once no version uses the old one, drop it in a later release. Never rename in place while two app versions run.
• Q: Why can blue/green rollback be unsafe?
  Both environments share the database. If green ran an incompatible migration, flipping back to blue runs old code against a new schema. Rollback is only instant if the schema stays compatible with both versions.
• Q: Flyway vs Liquibase?
  Both version schema changes and track applied ones in a history table. Flyway is SQL-first with versioned files; Liquibase uses changesets in XML/YAML/JSON/SQL, with preconditions and rollback blocks. In practice teams roll forward rather than roll back.
• Q: Rollback or roll forward?
  Roll back application changes first when it is safe, because it is fastest. Roll forward when data or schema has moved on irreversibly or when a tiny fix is quicker. Decide the plan before the release.
• Q: How do you make API and message changes backward compatible?
  Additive only: new optional fields, tolerant readers that ignore unknown fields, deprecate before removing, version when you must break, and schema-registry compatibility checks for events. Deploy providers before consumers for additions.
• Q: What do Argo Rollouts and Flagger do?
  They automate progressive delivery on Kubernetes: shift traffic in steps, evaluate metrics (typically from Prometheus) at each step, and promote or abort. Argo Rollouts replaces Deployment with a Rollout resource; Flagger watches an existing Deployment through a Canary resource.
• Q: How do you do canary on AWS?
  ALB listener rules with weighted target groups that your pipeline adjusts step by step, or CodeDeploy traffic-shifting configurations such as CodeDeployDefault.ECSCanary10Percent5Minutes for ECS and canary configurations for Lambda, with CloudWatch alarms triggering automatic rollback.
• Q: Canary vs A/B test?
  A canary checks the health of a new version on a share of requests. An A/B test compares business outcomes between sticky user cohorts. Similar routing, different goal and duration.
• Q: What is shadow traffic and what is the danger?
  Copying production requests to a new version while discarding its responses, to test it on real traffic with no user impact. The danger is side effects (payments, emails, writes), so the shadow must be isolated.
• Q: What would you check right after a deploy?
  Smoke tests, version endpoint, golden signals versus baseline for a bake time, new error signatures in logs, dependency and queue health, and business KPIs, before promoting and cleaning up.