---

Introduction

In traditional deployments, developers build Docker images on their local machines or CI/CD servers before pushing them to a container registry.

OpenShift provides a unique feature called BuildConfig, which automates this entire process inside the OpenShift cluster. Instead of manually creating Docker images, OpenShift can fetch your source code from Git, compile your application, create a container image, and deploy it automatically.

For Java developers, this simplifies the deployment process and integrates seamlessly with Git repositories and CI/CD pipelines.

---

Learning Objectives

By the end of this article, you will understand:

• What is BuildConfig?
• Why BuildConfig is useful
• Source-to-Image (S2I)
• Binary Builds
• Docker Builds
• Build Triggers
• Build Lifecycle
• Spring Boot BuildConfig
• Enterprise CI/CD workflow
• Best practices

---

Traditional Build Process

Without BuildConfig, developers typically follow these steps:

flowchart LR
    A[Developer]
    --> B[Git Repository]
    --> C[Maven Build]
    --> D[Docker Build]
    --> E[Container Registry]
    --> F[OpenShift Deployment]

This requires Docker installed on the developer or CI server.

---

OpenShift BuildConfig Workflow

BuildConfig automates the build inside OpenShift.

flowchart LR
    A[Developer]
    --> B[Git Repository]
    --> C[BuildConfig]
    --> D[Source-to-Image Build]
    --> E[ImageStream]
    --> F[Deployment]
    --> G[Running Pods]

No local Docker build is required.

---

What is BuildConfig?

A BuildConfig is an OpenShift resource that defines:

• Source code location
• Build strategy
• Output image
• Build triggers
• Environment variables

Think of it as a blueprint that tells OpenShift how to build your application.

---

BuildConfig Architecture

flowchart TD
    GIT["Git Repository"]
    BC["BuildConfig"]
    BUILD_POD["Build Pod"]
    IS["ImageStream"]
    DEPLOY["Deployment"]
    PODS["Pods"]

    GIT --> BC
    BC --> BUILD_POD
    BUILD_POD --> IS
    IS --> DEPLOY
    DEPLOY --> PODS

---

Build Strategies

OpenShift supports multiple build strategies.

Strategy	Description
Source-to-Image (S2I)	Builds directly from source code
Docker Build	Uses a Dockerfile
Binary Build	Upload pre-built binaries
Custom Build	Custom builder image

For Java applications, Source-to-Image (S2I) is the most commonly used strategy.

---

Source-to-Image (S2I)

S2I is an OpenShift feature that builds container images directly from source code.

Process:

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    BC["BuildConfig"]
    BUILDER["S2I Builder Image"]
    BUILD["Build Pod"]
    IS["ImageStream"]
    DEPLOY["Deployment"]
    POD["Application Pod"]

    DEV --> GIT
    GIT --> BC
    BC --> BUILDER
    BUILDER --> BUILD
    BUILD --> IS
    IS --> DEPLOY
    DEPLOY --> POD

Advantages:

• No Dockerfile required
• Automated builds
• Faster developer onboarding

---

Binary Build

In a Binary Build, developers build the JAR locally and upload it.

flowchart LR
    DEV["Developer"]
    JAR["Spring Boot JAR"]
    BC["BuildConfig (Binary)"]
    BUILDPOD["Build Pod"]
    IS["ImageStream"]
    DC["Deployment"]
    POD["Application Pod"]

    DEV --> JAR
    JAR --> BC
    BC --> BUILDPOD
    BUILDPOD --> IS
    IS --> DC
    DC --> POD

Useful for:

• Offline environments
• Pre-built artifacts
• Secure internal builds

---

Docker Build Strategy

Docker Build uses a Dockerfile.

flowchart LR
    DEV["Developer"]
    GIT["Git Repository"]
    DOCKERFILE["Dockerfile"]
    BUILD["Docker Build"]
    IMAGE["Container Image"]
    REG["Image Registry"]
    DEPLOY["Deployment"]
    POD["Application Pod"]

    DEV --> GIT
    GIT --> DOCKERFILE
    DOCKERFILE --> BUILD
    BUILD --> IMAGE
    IMAGE --> REG
    REG --> DEPLOY
    DEPLOY --> POD

Choose this approach when you need full control over the image.

---

BuildConfig Lifecycle

sequenceDiagram

participant Developer

participant Git

participant BuildConfig

participant Build Pod

participant ImageStream

participant Deployment

Developer->>Git: Push Code

Git->>BuildConfig: Webhook

BuildConfig->>Build Pod: Start Build

Build Pod->>ImageStream: Push Image

ImageStream->>Deployment: Trigger Deployment

---

Spring Boot BuildConfig Example

apiVersion: build.openshift.io/v1
kind: BuildConfig

metadata:
  name: springboot-demo

spec:

  source:
    git:
      uri: https://github.com/codewithvenu/springboot-demo.git

  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: openjdk-21:latest

  output:
    to:
      kind: ImageStreamTag
      name: springboot-demo:latest

---

Creating a BuildConfig

oc apply -f buildconfig.yaml

Verify:

oc get buildconfigs

---

Start a Build

oc start-build springboot-demo

Watch progress:

oc logs -f build/springboot-demo-1

---

Build Triggers

BuildConfig supports automatic triggers.

Trigger	Purpose
GitHub Webhook	Build after Git push
Generic Webhook	External automation
Config Change	Build after BuildConfig changes
Image Change	Build after base image updates
Manual	Developer starts build

---

Git Webhook Flow

flowchart LR

Developer

--> GitHub

GitHub

--> Webhook

Webhook

--> BuildConfig

BuildConfig

--> Build

Build

--> ImageStream

Every Git push automatically starts a new build.

---

ImageStream Integration

BuildConfig works closely with ImageStreams.

flowchart LR

Build

--> ImageStream

ImageStream

--> Deployment

Deployment

--> Pods

When a new image is created, deployments can be triggered automatically.

---

Enterprise Banking Example

Suppose a Payment API is updated.

flowchart LR
    DEV["Developer"]
    GITHUB["GitHub"]
    BC["BuildConfig"]
    BUILD["Maven Build"]
    IMAGE["Container Image"]
    IS["ImageStream"]
    DEPLOY["Payment Deployment"]
    USERS["Customers"]

    DEV --> GITHUB
    GITHUB --> BC
    BC --> BUILD
    BUILD --> IMAGE
    IMAGE --> IS
    IS --> DEPLOY
    DEPLOY --> USERS

This enables fully automated continuous delivery.

---

Build Logs

View all builds:

oc get builds

Inspect logs:

oc logs build/springboot-demo-1

Typical output:

Cloning repository...
Running Maven build...
Packaging Spring Boot application...
Pushing image...
Build completed successfully.

---

Cancel a Build

oc cancel-build springboot-demo-3

Useful if a build was triggered accidentally.

---

Rebuild After Changes

oc start-build springboot-demo

No need to recreate the BuildConfig.

---

Source-to-Image vs Docker Build

S2I	Docker Build
No Dockerfile	Requires Dockerfile
Faster setup	More customization
Java optimized	Any application
OpenShift native	Standard Docker
Simple maintenance	Full control

---

Best Practices

• Store source code in Git.
• Use S2I for standard Spring Boot applications.
• Use Docker builds when custom images are required.
• Enable Git webhooks.
• Keep BuildConfig under version control.
• Use immutable image tags for production.
• Monitor build logs regularly.
• Separate Dev, QA, and Production BuildConfigs.

---

Common Mistakes

❌ Running manual builds for every deployment.

❌ Using latest tags in production.

❌ Ignoring failed build logs.

❌ Hardcoding credentials.

❌ Keeping BuildConfig outside source control.

---

Advantages of BuildConfig

• Automated builds
• Git integration
• Faster deployments
• CI/CD ready
• Native OpenShift feature
• Supports webhooks
• Image automation
• Simplifies Java application deployment

---

Summary

BuildConfig is one of OpenShift's most powerful developer features.

Key takeaways:

• BuildConfig automates application builds inside OpenShift.
• S2I is ideal for standard Spring Boot applications.
• Docker Build provides maximum flexibility.
• Binary Build supports pre-built artifacts.
• Build triggers enable continuous integration.
• ImageStreams integrate builds with deployments automatically.

Using BuildConfig allows Java developers to focus on writing code while OpenShift handles image creation and deployment.

---

Interview Questions

1. What is BuildConfig in OpenShift?
2. What is Source-to-Image (S2I)?
3. What are the different Build Strategies?
4. What is an ImageStream?
5. What triggers a BuildConfig?
6. How do you start a build manually?
7. When should you use Binary Builds?
8. What is the difference between Docker Build and S2I?
9. How do BuildConfigs support CI/CD?
10. Why are BuildConfigs useful for Spring Boot applications?

---