A Practical Path from a Legacy Python EKS Stage Environment to Production

Moving an application from a stage Amazon EKS environment into production is not simply a matter of promoting a container image. The work becomes more demanding when the workload runs on a legacy Python runtime, sits behind Cloudflare, must satisfy a zero-issue SonarQube quality gate, and needs reliable CI/CD validation.

The useful goal is not “deploy to production quickly.” It is to establish a repeatable production path: build an immutable artifact, prove it meets the agreed quality and security controls, deploy it predictably, expose it safely through the edge, and retain enough evidence to diagnose or roll back a failed release.

Start with a production-readiness contract

Before changing infrastructure or pipeline code, define what “ready” means. A concise readiness contract prevents teams from discovering incompatible assumptions during a release window.

• Runtime: the required Python version, base image, dependencies, process entry point and environment variables are explicit.
• Artifact: the same versioned container image is promoted from validated stages to production; production does not rebuild from a different branch or dependency state.
• Deployment: Kubernetes manifests or a chart define replicas, resource requests and limits, health checks, configuration references, service account and rollout behaviour.
• Ingress: the DNS, TLS and Cloudflare configuration path is documented, including the production hostname and origin routing model.
• Quality: the SonarQube project, branch or pull-request analysis approach, quality profile, quality gate and definition of “zero issues” are agreed.
• Validation: CI/CD must demonstrate the checks that block promotion, the checks that run after deployment, and the rollback decision path.
• Operations: owners know how to inspect logs, workload status, recent deployment changes and edge-to-origin failures.

“Zero SonarQube issues” needs particular care. It should be converted into an executable policy, not left as a slogan. Confirm whether it means no newly introduced issues, no issues of particular severities, no unresolved issues across the whole codebase, or a specific quality-gate result. These interpretations produce very different delivery effort and should not be assumed to be equivalent.

Inventory the stage workload before designing production

A stage EKS deployment is valuable evidence, but it is not automatically a production blueprint. Capture the current state and separate intentional configuration from accumulated drift.

At minimum, review the application repository, dependency definition, container build, pipeline definition, Kubernetes resources, configuration injection mechanism, service accounts, ingress or load-balancer path, DNS ownership, and Cloudflare settings relevant to the hostname. Compare stage manifests and configuration with the intended production design rather than copying every setting.

For a legacy Python 3.6 workload, make runtime compatibility an explicit workstream. Identify the interpreter location, packaging tool, dependency pins, native build dependencies and test runtime. Build the image in CI and run the service in an environment that resembles the target cluster. This reveals failures caused by unavailable packages, outdated build tooling, incompatible operating-system libraries or assumptions embedded in startup scripts.

Do not combine runtime modernisation and production migration without a decision. If the immediate requirement is production deployment, a tightly controlled migration may be the safer bounded change. If the current runtime cannot be built, tested or operated reliably in the required environment, the upgrade becomes a release prerequisite. Either way, record the rationale, the owner and the resulting risk.

Build once and promote the same artifact

A production pipeline should create a traceable relationship between source revision, test results, code analysis and deployed image. A practical sequence is:

1. Check out a specific commit and install dependencies deterministically.
2. Run formatting, linting and unit tests that are supported by the project.
3. Run SonarQube analysis and wait for the agreed quality-gate result.
4. Build a container image tagged with an immutable identifier, such as the commit revision.
5. Run relevant container or application smoke checks.
6. Publish the image to the approved registry only after required checks pass.
7. Deploy that exact image reference to the target environment using reviewed deployment configuration.
8. Run post-deployment checks and retain the deployment result with the release record.

Keep environment-specific values out of the image. Cluster endpoints, credentials, hostnames and similar values should be supplied through the deployment mechanism and appropriate secret handling. This reduces the risk of a stage-specific setting reaching production and makes the artifact promotable.

CI/CD validation should include failure paths. Deliberately test that an analysis failure blocks promotion, an invalid manifest is rejected before deployment, a failed readiness check prevents a completed rollout, and an unhealthy release can be reverted to the previously known artifact. A pipeline that only proves the happy path is not yet a dependable production control.

Make SonarQube compliance actionable

Quality analysis is most useful when it provides a clear engineering queue. First, ensure analysis runs against the same source revision that will produce the release image. Then establish a baseline: identify existing findings, newly introduced findings and findings that genuinely require remediation before production.

When the requirement is zero issues, avoid suppressing or excluding findings merely to obtain a passing result. Each exception should have a documented technical reason, a scope, an owner and a review point. Otherwise the quality gate becomes a reporting exercise rather than a safeguard.

For Python services, analysis is stronger when tests produce coverage information in a format consumed by the scanner, when source and test paths are correctly configured, and when generated or vendored content is deliberately handled. The exact scanner properties depend on the project, so validate them against the repository and the configured SonarQube project rather than copying settings from another service.

Design the EKS deployment for observable failure

Kubernetes configuration should make it easy to determine whether an application is running, ready to receive traffic and healthy over time. Define resource requests and limits based on observed application needs and revise them after measured production behaviour. Add readiness probes that represent whether the service can serve requests and liveness probes only where restarting an unhealthy process is the correct response.

Use a controlled rollout strategy. Ensure the deployment can retain available capacity while a new replica is validated, and set a progress deadline that causes a stuck rollout to surface as a failure. Record the prior image reference so rollback does not depend on reconstructing a release under pressure.

Production configuration also needs clear boundaries. Namespace, service account permissions, secrets, config maps, network exposure and ingress resources should be reviewed as part of the release design. Avoid granting broad permissions simply to resolve an initial deployment error. A narrow, understood permission model is easier to operate and audit.

Validate the Cloudflare-to-origin path end to end

Cloudflare integration adds an edge layer that must be tested separately from the application pod. Document the intended request path: public hostname, Cloudflare DNS record, Cloudflare proxy behaviour where applicable, origin hostname or load balancer, Kubernetes ingress or service, and application endpoint.

Before opening production traffic, validate DNS resolution, TLS certificate behaviour, host-header routing and an application health endpoint through the public hostname. Then compare that result with a controlled origin-side test where appropriate. This distinction helps isolate whether a failure is in the edge configuration, DNS, certificate handling, load-balancer routing, ingress, or the application itself.

Be deliberate about client IP handling, redirects, caching rules and timeouts. These settings can change application behaviour even when the pods are healthy. Test expected error responses as well as successful requests, and ensure logs contain enough request context to correlate an edge-facing failure with the relevant service or deployment.

Use a staged release and evidence-based go/no-go decision

For the first production release, use the smallest safe exposure consistent with the application’s traffic model. A staged rollout may involve a restricted endpoint, an internal validation window, or a limited traffic strategy where the platform supports it. The mechanism matters less than having explicit entry and exit criteria.

A practical go/no-go checklist includes a passing quality gate, successful artifact build, approved deployment configuration, healthy Kubernetes rollout, working Cloudflare hostname and TLS path, successful smoke tests, observable logs and metrics, and a tested rollback command or procedure. If a criterion fails, stop and diagnose the failed layer rather than bypassing the control to meet a date.

After release, capture what changed and what was learned. Update the runbook with the image identifier, deployment revision, validation evidence, known operational signals and rollback path. This turns a one-time migration into a reusable production delivery pattern.

Where specialist platform engineering helps

This class of work crosses application delivery, Kubernetes, edge routing, CI/CD and engineering controls. X-ITM can help teams assess the current delivery path, define a bounded production-readiness plan, and implement repeatable platform engineering controls for reliable releases. Learn more at X-ITM.