CI/CD and DevOps with OpenShift

How OpenShift Fits into DevOps and CI/CD

OpenShift is designed to support DevOps practices by integrating source control, image builds, deployments, and operations into a single platform. It provides:

• A unified API for building, deploying, and running applications.
• Built‑in objects and controllers that map directly to CI/CD concepts.
• Tight integration with Git, container registries, and pipeline engines.

Instead of separate, loosely connected systems, OpenShift lets you define most of your delivery workflows as Kubernetes-native resources.

Key DevOps goals that OpenShift helps with:

• Automation: Builds, tests, deployments, and rollbacks can be automated and triggered from code changes.
• Consistency: The same manifests and pipelines can run across environments.
• Shift left: Policies, security scans, and quality checks can run as part of the build and deployment pipelines.
• Self-service: Development teams can create and manage their own pipelines and environments within defined guardrails.

OpenShift Concepts Relevant to CI/CD

Several core OpenShift concepts map naturally to CI/CD stages:

• Git repositories: System of record for application source and configuration.
• Image builds: Using Dockerfiles or Source-to-Image (S2I) strategies to create container images.
• ImageStreams: Track and manage image versions; can trigger builds and deployments when images change.
• BuildConfigs: Define how images are built and when to trigger builds.
• DeploymentConfigs/Deployments: Define how applications are rolled out to the cluster.
• Routes/Services: Expose running applications for testing and production access.
• Pipelines: Implement multi-step workflows (build, test, scan, deploy, etc.).

These objects are all managed declaratively via YAML and the OpenShift API, enabling “pipelines as code.”

OpenShift Build and Deployment Flow in a DevOps Context

A typical OpenShift-centric delivery flow looks like:

1. Developer commits code to a Git repository (e.g., GitHub, GitLab, Bitbucket).
2. Webhook triggers a build in OpenShift:
• A BuildConfig is configured to listen to Git webhooks.
3. Image is built:
• Using S2I or a Dockerfile defined in the repo.
• The resulting image is stored in the internal registry and tracked via an ImageStream.
4. Deployment is triggered:
• A Deployment or DeploymentConfig watches the ImageStream.
• When a new image tag appears (e.g., :latest or :v1.2.3), a new rollout is started.
5. Post-deployment checks:
• Health checks and readiness probes validate the rollout.
• Automated tests can be run against the newly deployed environment.
6. Promotion:
• The same image can be promoted between environments (dev → test → prod) via new tags in ImageStreams, rather than rebuilding.

This aligns with CI/CD practices while reusing platform-native primitives.

Triggers and Automation in OpenShift

OpenShift provides built-in triggers to automate build and deployment steps without an external CI system:

• Git triggers on BuildConfig:
• A push to the repository can trigger a new build via webhooks.
• Image change triggers:
• A Deployment or DeploymentConfig can start a rollout when a watched ImageStreamTag is updated.
• Config change triggers:
• Changes to a deployment configuration can trigger a new deployment.

Example conceptual flow with triggers:

1. Git push → Git webhook → BuildConfig → new image built.
2. New image → ImageStream updated → deployment trigger fires.
3. Rollout occurs → application updated with minimal manual intervention.

This native automation is often combined with more advanced CI/CD frameworks, but it’s sufficient for many teams starting with DevOps on OpenShift.

Pipelines as Code and Git-Centric Workflows

In a DevOps mindset, everything that defines delivery (build steps, tests, policies, deployment steps) should live in version control:

• Pipeline definitions:
• Written as YAML (e.g., Tekton Pipeline/PipelineRun objects) or as declarative configs in external tools.
• Environment configuration:
• Namespaces, quotas, deployments, services, and routes defined as Kubernetes/OpenShift manifests.
• Promotion and releases:
• Implemented by merging branches, creating tags, or updating GitOps repositories that drive the cluster state.

OpenShift supports workflows such as:

• Feature branch pipelines: On every pull request, a pipeline builds and tests the application, optionally deploying to a short-lived environment.
• Main branch pipelines: On successful merge to main, a pipeline builds an image, runs tests, and deploys to a shared environment.
• Promotion pipelines: Controlled by Git merges or tag creation in an environment-specific config repository.

Dev, Test, and Prod Environments on OpenShift

OpenShift makes it straightforward to map DevOps environments to cluster structures:

• Projects/namespaces per environment:
• myapp-dev, myapp-test, myapp-prod, etc.
• Separate policies and permissions:
• Developers may have full control in dev, limited change rights in test, and read-only in prod.
• Shared or separate clusters:
• Some organizations run all environments in one multi-tenant cluster.
• Others use distinct clusters per environment and promote via GitOps or registry-based promotion.

For CI/CD on OpenShift, consider:

• Where pipelines run (single shared tools project vs per-team projects).
• How images move between environments (rebuilt per environment vs. built once, promoted via tags).
• What must be environment-specific (URLs, credentials, resource limits) vs. environment-agnostic (application image, base manifest templates).

Integrating OpenShift with External CI/CD Systems

OpenShift does not force you to use one particular CI/CD engine. Common integration patterns include:

• External CI, OpenShift as target:
• Tools like Jenkins, GitLab CI, GitHub Actions, Azure DevOps, etc., run builds and tests.
• Pipelines then:
• Build images (locally or in OpenShift).
• Push to the OpenShift internal or external registry.
• Apply or update OpenShift manifests via oc or Kubernetes APIs.
• Hybrid approach:
• External CI handles compilation, tests, and artifact creation.
• OpenShift-native pipelines handle deployment, environment provisioning, and in-cluster tests.

Typical integration tasks:

• Configuring service accounts and API tokens so CI jobs can access OpenShift.
• Using the oc CLI or Kubernetes clients within CI jobs to:
• Deploy manifests.
• Trigger rollouts.
• Watch rollout status.
• Publishing build artifacts (images) to:
• OpenShift’s internal registry, or
• An external registry that OpenShift pulls from.

Policy, Security, and Quality Gates in DevOps with OpenShift

A key DevOps practice is embedding controls into the delivery pipeline so that quality and security checks run automatically:

• Security scanning:
• Integrate image scanning in build or pipeline stages; only sign-off or tag images as “prod-ready” after successful scans.
• Admission controls and policies:
• Enforce rules on what can be deployed:
• Valid labels and annotations.
• Allowed base images.
• Requirements on resource limits, security contexts, etc.
• Quality gates:
• Block promotions or deployments if:
• Automated tests fail.
• Performance thresholds are not met.
• Compliance checks do not pass.

These gates are implemented by combining:

• CI/CD pipelines (to run checks).
• OpenShift policies and controllers (to enforce cluster rules).
• Approval workflows (manual or automated) for high-risk environments like production.

Observability and Feedback into DevOps Loops

In DevOps, feedback from running systems should influence future changes. On OpenShift this typically means:

• Pipelines publish deployment metadata:
• Build number, Git commit, branch, and pipeline run ID annotated onto Pods, Deployments, and Routes.
• Monitoring and logging tools:
• Provide visibility into the effect of each deployment: error rates, latency, resource usage, and user impact.
• Rollbacks and progressive delivery:
• Use deployment strategies that allow rapid rollback if metrics degrade.
• Integrate canary or blue‑green deployments into pipelines so only a subset of traffic sees new versions initially.

This closes the loop between code changes, deployment, and operational outcomes—central to DevOps culture.

Organizational and Process Considerations

Technical features alone do not create DevOps. When adopting CI/CD on OpenShift, teams usually need to address:

• Ownership:
• Who owns application pipelines (development teams vs central platform team)?
• Who maintains shared templates and best practices?
• Standardization vs flexibility:
• Standard pipeline templates and base images promote consistency and security.
• Team-specific extensions allow for domain-specific testing or release steps.
• Onboarding and guardrails:
• Provide starter templates and golden paths for new teams on OpenShift.
• Use RBAC, quotas, and policies to keep self-service safe and manageable.

OpenShift acts as the common runtime and API surface around which these practices are built, but each organization typically customizes the exact DevOps workflows.

Summary

CI/CD and DevOps with OpenShift center on:

• Treating everything—source, pipelines, manifests—as code in Git.
• Using OpenShift-native resources (BuildConfigs, ImageStreams, Deployments, Routes, Pipelines) to implement automated workflows.
• Integrating external CI/CD tools where appropriate, with OpenShift as the deployment and runtime platform.
• Embedding security, quality, and operational feedback directly into the delivery pipeline.

Subsequent chapters will explore specific mechanisms—such as OpenShift Pipelines and GitOps—in more depth.