OpenShift Builds for Java, Python & C++ and CI/CD Deployment via Harness

Technical Blog about OpenShift Builds for Java, Python & C++, and CI/CD Deployment via Harness.

1.Executive Summary

Modern engineering teams need a build and deployment platform that can handle polyglot workloads consistently, securely, and at speed. This whitepaper describes Lightspeed, a reference architecture that standardizes application builds on Red Hat OpenShift for three representative language ecosystems — Java, Python, and C++ — and pairs those builds with Harness as the continuous delivery (CD) engine for promotion into staging and production.

The goal is a single, repeatable pattern that development teams can adopt regardless of language: source goes into OpenShift as a container image through a defined build strategy, the image is scanned and tagged, and Harness takes over from there to orchestrate progressive delivery, approvals, and rollback across environments.

This document covers the OpenShift build strategies available for each language, sample configuration, the Harness pipeline model used for deployment, recommended deployment strategies, and the security and observability practices that should accompany the platform.

2.Objectives & Scope

Provide a consistent, repeatable build process on OpenShift for Java, Python, and C++ and many more.

Standardize image build strategy selection (Source-to-Image vs. Docker/container builds) based on language and runtime constraints.

Define a Harness CD pipeline pattern that consumes OpenShift-built images and deploys them across dev, staging, and production.

Establish baseline practices for image scanning, promotion gates, and rollback.

Scope excludes: source control branching strategy, cost management, and cluster capacity planning, which are treated as separate workstreams.

3.Architecture Overview

The platform is organized around a clean separation of concerns: OpenShift owns build and image lifecycle, and Harness owns release orchestration and deployment governance. The high-level flow is as follows:

Developer pushes code to the source repository (Git). OpenShift BuildConfig is triggered (webhook, image change, or manual) and produces a container image using the strategy appropriate to the language. The resulting image is pushed to the internal OpenShift image registry (or an external registry such as Quay/ECR/ACR) and tagged with the build/commit identifier. Image is scanned for vulnerabilities as part of the build pipeline (e.g., via an integrated scanner or a Tekton task). Harness picks up the new image tag (via trigger or artifact polling) and runs its deployment pipeline against the target OpenShift/Kubernetes namespace. Harness applies the chosen deployment strategy (rolling, canary, or blue-green), runs verification steps, and either promotes or rolls back.

Keeping build (OpenShift) and deploy (Harness) as distinct, loosely coupled stages allows each language team to iterate on build specifics without touching the deployment pipeline, and allows platform/DevOps teams to evolve deployment governance without needing to understand every language's build toolchain.

4.OpenShift Build Strategies

OpenShift supports several build strategies. Selecting the right one per language reduces Dockerfile maintenance and takes advantage of curated, patched base images where possible.

Strategy	How it works	Best fit
Source-to-Image (S2I)	Injects application source into a prebuilt, language-specific builder image; the builder handles compiling/packaging.	Java (Maven/Gradle) and Python, where Red Hat-maintained S2I builder images exist and are kept patched.
Docker / Container build	Builds directly from a Dockerfile checked into the repository, giving full control over the build steps.	C++ and any workload without an official S2I builder, or where a multi-stage build is required.
Pipeline build (Tekton)	Chains multiple tasks (build, test, scan, push) into a single Pipeline/PipelineRun resource.	Teams standardizing CI steps across all three languages under one pipeline definition.

5.Language Specific Build Setup

5.1. Java (Maven/Gradle) via Source-to-Image

For Maven projects with private artifact repositories, mount settings.xml via a ConfigMap and reference it in the BuildConfig's source secrets so credentials are never committed to the repository.

oc new-build registry.redhat.io/ubi8/openjdk-17:latest~https://github.com/org/java-app.git --name=java-app-build
oc start-build java-app-build --follow

5.2 Python via Source-to-Image

Python applications use the Red Hat UBI Python S2I image. The builder automatically detects requirements.txt and installs dependencies during the build, producing a runnable image without a hand-written Dockerfile.

oc new-build registry.redhat.io/ubi8/python-311:latest~https://github.com/org/python-app.git --name=python-app-build
oc start-build python-app-build --follow

For projects relying on native extensions or system packages beyond what the base image provides, a small .s2i/bin/assemble override script can be added to the repository to install additional OS packages before the pip install step.

5.3 C++ via Docker/Container Build

C++ has no standard OpenShift S2I builder, so a multi-stage Dockerfile build is used instead. The multi-stage pattern keeps the final runtime image minimal by discarding compilers and build tooling after the binary is produced.

FROM registry.access.redhat.com/ubi8/ubi:latest AS build
RUN dnf install -y gcc-c++ cmake make && dnf clean all
COPY . /src
WORKDIR /src
RUN cmake -S . -B build && cmake --build build --config Release

FROM registry.access.redhat.com/ubi8/ubi-minimal:latest
COPY --from=build /src/build/app /usr/local/bin/app
ENTRYPOINT ["/usr/local/bin/app"]

oc new-build --strategy=docker --binary --name=cpp-app-build
oc start-build cpp-app-build --from-dir=. --follow

6.Sample BuildConfig Reference

Once OpenShift produces a tagged, scanned image, Harness takes ownership of promoting that artifact through environments. Harness is configured with a Kubernetes / OpenShift cloud provider connector and an artifact source pointed at the OpenShift internal registry (or the external registry used for image storage).

Field	Java / Python (S2I)	C++ (Docker)
strategy.type	SourceStrategy	DockerStrategy
source.type	Git or Binary	Git or Binary
output.to	ImageStreamTag: app:latest	ImageStreamTag: app:latest
triggers	ConfigChange, ImageChange, GitHub webhook	ConfigChange, GitHub webhook

7.Continuous Delivery with Harness

7.1 Pipeline Stages

• Artifact Trigger — Harness listens for a new image tag pushed by the OpenShift build (via webhook or polling trigger).

• Dev Deployment — Automatic rollout to the development namespace using a rolling update strategy for fast feedback.

• Automated Verification — Smoke tests / health checks run against the dev deployment; failures halt the pipeline automatically.

• Approval Gate — Manual or policy-based approval before promotion to staging/production.

• Staging Deployment — Canary or blue-green rollout with automated analysis (e.g., error rate, latency) before full traffic shift.

• Production Deployment — Same strategy as staging, gated by a second approval and with automatic rollback configured on failed verification.

7.2 Deployment Strategies

Strategy	Description	When to use
Rolling	Instances replaced incrementally; no full environment duplication needed.	Dev/low-risk environments where speed matters more than blast-radius control.
Canary	Small percentage of traffic shifted to the new version first, then increased gradually based on health signals.	Staging and production for services with meaningful traffic and monitoring in place.
Blue-Green	Full duplicate environment stood up; traffic cut over once validated, old kept for rollback.	Production services needing instant rollback and zero-downtime cutover.

7.3 Harness ↔ OpenShift Integration Checklist

• Create a Harness Kubernetes connector using the OpenShift cluster's service account token and API server URL.

• Grant the service account the minimum RBAC needed: manage Deployments/DeploymentConfigs, Services, Routes, and read ImageStreams in the target namespaces.

• Configure an artifact source in Harness pointing to the OpenShift internal registry or external registry, keyed on the same tagging convention used by the BuildConfigs.

• Define one Harness environment per OpenShift namespace (dev, staging, production) with environment-specific values/overrides.

Wire the OpenShift build's post-build webhook (or a Tekton task) to call the Harness trigger API on successful image push.

8.Security & Compliance Considerations

Scan every image for known vulnerabilities immediately after build, before it becomes eligible for deployment; fail the pipeline on critical findings.

Use OpenShift image streams and tag immutability so a given tag always resolves to the same digest once promoted.

Store all registry, source, and cluster credentials as OpenShift Secrets / Harness Secret Manager entries — never in BuildConfig or pipeline YAML directly.

Apply least-privilege RBAC for both the OpenShift build service accounts and the Harness deployment service account, scoped per namespace.

Require an approval step in Harness before any production promotion, with an audit trail of who approved and when.

9.Monitoring & Observability

Emit build metrics (duration, success/failure rate) from OpenShift builds to the shared monitoring stack (e.g., Prometheus) for trend analysis.

Use Harness's built-in deployment verification (metrics/log analysis) during canary and blue-green rollouts to automate the go/no-go decision.

Centralize application logs and cluster events so a failed deployment can be diagnosed without needing separate access to each language team's tooling.

Track deployment frequency, change failure rate, and mean time to restore (MTTR) as the core DORA metrics for the platform.

10.Best Practices Checklist

Standardize on one image tagging convention across all languages (recommended: app:git-sha).

Keep language-specific build logic (Maven settings, pip options, CMake flags) inside the application repository, not in shared platform config.

Treat the C++ Dockerfile as a first-class, reviewed artifact since it lacks the guardrails of a maintained S2I builder image.

Automate promotion gates wherever possible; reserve manual approval for production only.

Review RBAC and secret scope quarterly as teams and namespaces change.

11.Conclusion

Lightspeed demonstrates that a polyglot engineering organization does not need a bespoke pipeline per language. By standardizing on OpenShift's native build strategies — Source-to-Image for Java and Python, and a controlled Docker build for C++ — and handing off a consistently tagged, scanned image to Harness for deployment, teams gain a predictable path from commit to production. The separation between build (OpenShift) and release (Harness) keeps each layer simple, auditable, and independently improvable as the platform matures.