OpenShift CI/CD with GitHub Actions

Why This Matters

Build and deploy Spring Boot to OpenShift from GitHub Actions using oc commands and secure credentials.

In real projects, OpenShift is not only a place where containers run. It is the platform where developers, DevOps engineers, security teams, and operations teams collaborate around one application lifecycle. This lesson explains the concept, shows the practical commands, and gives you a production checklist you can reuse.

Where It Fits In The Learning Path

Area	Details
Module	DevOps and CI/CD
Primary user	Java developer, backend engineer, DevOps engineer
Main outcome	You can explain and apply OpenShift CI/CD with GitHub Actions in an OpenShift project
Example app	Spring Boot payments-api service

Data Flow

flowchart LR
    Dev[Developer] --> Git[Git Repository]
    Git --> Build[OpenShift Build or CI Pipeline]
    Build --> Image[Container Image]
    Image --> Deploy[Deployment]
    Deploy --> Pod[Running Pods]
    Pod --> Service[Service]
    Service --> Route[Route or Internal DNS]
    Route --> User[Client or Consumer]

Step By Step Implementation

1. Select the correct OpenShift project for the application.
2. Prepare the Spring Boot artifact, container image, or deployment manifest.
3. Apply the OpenShift resource.
4. Verify Pods, Services, Routes, logs, and health checks.
5. Promote the same pattern through dev, test, staging, and production.

Commands You Can Copy

oc login "$OPENSHIFT_SERVER" --token="$OPENSHIFT_TOKEN"
oc project payments-dev
oc apply -f k8s/
oc rollout status deployment/payments-api

Example Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: payments-api
  template:
    metadata:
      labels:
        app: payments-api
    spec:
      containers:
        - name: payments-api
          image: image-registry.openshift-image-registry.svc:5000/payments-dev/payments-api:latest
          ports:
            - containerPort: 8080

Input And Output Example

Input	Expected output
Application source code or manifest	OpenShift resource is created or updated
oc get pods	Pods show Running or a clear failure reason
oc logs deployment/payments-api	Spring Boot startup logs and request logs are visible
Route or service URL	API returns a successful response or health status

Production Checklist

• Use clear naming for project, app, service, and route resources.
• Keep environment-specific values outside the application jar.
• Configure readiness and liveness probes for every service.
• Set CPU and memory requests before moving to production.
• Store passwords, tokens, and keys in Secrets, not ConfigMaps.
• Use least privilege RBAC for users, pipelines, and ServiceAccounts.
• Validate logs, metrics, alerts, and rollback steps before release.

Common Mistakes

Mistake	Better approach
Hard-coding environment values	Use ConfigMaps, Secrets, and environment variables
Deploying without probes	Add readiness, liveness, and startup probes
Running one replica in production	Use multiple replicas and anti-affinity when needed
Giving broad permissions	Use namespace-scoped roles and least privilege
Ignoring resource limits	Define requests and limits based on load testing

Interview Notes

When explaining OpenShift CI/CD with GitHub Actions, connect the concept to operational value: faster releases, safer configuration, better security, and easier troubleshooting. Strong answers usually include both the OpenShift resource name and the runtime behavior it creates.

Quick Recap

• OpenShift CI/CD with GitHub Actions belongs to the DevOps and CI/CD part of the OpenShift platform.
• The practical workflow is create, deploy, expose, observe, and improve.
• For Spring Boot applications, always think about configuration, security, health checks, scaling, and logs together.