DEV Community: Bhagirath

End-to-End CI/CD Pipeline Using Jenkins and Kubernetes

Bhagirath — Tue, 20 Jan 2026 03:40:05 +0000

Building Scalable, Cloud-Native CI/CD Pipelines with Jenkins and Kubernetes

In modern DevOps workflows, running Jenkins on static or long-lived build agents often leads to scalability issues, inefficient resource usage, and maintenance overhead. As applications grow and deployment frequency increases, CI/CD systems must be dynamic, resilient, and cloud-native.

Kubernetes solves these challenges by providing on-demand, isolated, and auto-scalable environments for Jenkins workloads. By integrating Jenkins with Kubernetes, teams can dynamically provision build agents as pods, optimize resource utilization, and build highly scalable CI/CD pipelines.

In this blog, you’ll learn how Jenkins integrates with Kubernetes for CI/CD, understand the pipeline architecture, set up Jenkins on Kubernetes, and build a production-ready CI/CD pipeline using containerized workloads and Kubernetes deployments.

1. Why Integrate Jenkins with Kubernetes for CI/CD?

Kubernetes provides a robust and scalable platform for running containerized applications, and Jenkins is a powerful tool for automating the CI/CD pipeline. When integrated, these two tools can provide significant benefits:

Dynamic Agent Provisioning: Jenkins dynamically creates Kubernetes pods as build agents for each pipeline run. Agents are provisioned only when needed and automatically destroyed after job completion, eliminating idle infrastructure.
Scalability: Kubernetes scales Jenkins agents based on workload demand. Multiple pipelines can run in parallel, allowing for faster builds and testing cycles.
Isolation: Each Jenkins job runs inside its own Kubernetes pod, ensuring clean, reproducible, and conflict-free build environments across pipelines.
Cloud-Native Deployment: Applications can be built, containerized, and deployed directly to Kubernetes *clusters, enabling seamless end-to-end CI/CD workflows in cloud-native environments.
Resource Efficiency: Because agents are short-lived and container-based, system resources are consumed only during active pipeline execution, significantly reducing infrastructure costs.

2. Prerequisites for Jenkins and Kubernetes CI/CD Integration

Before integrating Jenkins with Kubernetes, ensure you have the following prerequisites in place. These prerequisites form the foundation for a stable and production-ready CI/CD setup.

Kubernetes Cluster: A running Kubernetes cluster is required to host Jenkins agents and deploy applications. This can be a managed Kubernetes service such as Amazon EKS, Google GKE, Azure AKS, or a self-managed on-premise cluster.
Jenkins Installed: Jenkins must be installed and accessible. It can run:
- inside a Kubernetes cluster (recommended for cloud-native setups)
- on a standalone virtual machine or server.
Kubernetes Plugin for Jenkins: The Kubernetes Plugin enables Jenkins to dynamically provision Kubernetes pods as build agents. This plugin is essential for running CI/CD pipelines using Kubernetes-based agents.
Cluster Access and Permissions: Jenkins must have permission to communicate with the Kubernetes API server. This is typically achieved using a Kubernetes Service Account with the required RBAC roles.
kubectl: The kubectl CLI tool is useful for:
- managing Kubernetes resources
- debugging deployments
- running deployment steps inside Jenkins pipelines

3. Jenkins Kubernetes Integration Architecture

Jenkins integrates with Kubernetes using the Kubernetes Plugin, which allows Jenkins to run CI/CD jobs inside Kubernetes pods instead of on static build agents.

In this setup, Jenkins focuses on orchestrating the pipeline, while Kubernetes handles executing jobs and managing resources. Whenever a pipeline starts, Jenkins asks Kubernetes to spin up a temporary pod to run the job. Once the job finishes, the pod is automatically removed.

This makes the entire CI/CD system dynamic, scalable, and cloud-native.

How Jenkins and Kubernetes Work Together:

Jenkins Controller: Jenkins controller manages pipelines, jobs, and credentials. It does not run builds directly. Instead, it coordinates with Kubernetes to run jobs on demand.
Kubernetes Plugin: plugin connects Jenkins to the Kubernetes cluster and handles the creation and cleanup of agent pods whenever a pipeline is triggered
Kubernetes Agent Pods: Each CI/CD job runs inside its own Kubernetes pod. These pods are:
- created only when needed
- isolated from each other
- automatically destroyed after the job completes
Jenkins Pipeline: A Jenkinsfile defining the CI/CD steps, including build, test, and deployment stages.
Kubernetes Cluster: Kubernetes cluster provides the infrastructure where agent pods run and where applications are ultimately deployed.

4. CI/CD Pipeline Architecture with Jenkins and Kubernetes

This CI/CD architecture uses Jenkins as the pipeline orchestrator and Kubernetes as the execution and deployment platform. Instead of relying on static Jenkins agents, Kubernetes dynamically provisions build agents as pods, making the pipeline scalable and resource-efficient.

4.1. Git

The pipeline begins with a code change pushed to a Git repository (GitHub, GitLab, or Bitbucket).
A webhook triggers Jenkins automatically on every commit or pull request, ensuring that no manual intervention is required.

Role of Git:

Stores application source code and Dockerfile
Triggers Jenkins pipelines via webhooks
Acts as the single source of truth for builds

4.2. Jenkins Controller

The Jenkins controller manages the CI/CD pipeline logic defined in the Jenkinsfile.
When a build is triggered, Jenkins does not execute jobs on itself. Instead, it requests Kubernetes to create an ephemeral agent pod.

Key Responsibilities:

Parses the Jenkinsfile
Orchestrates pipeline stages (build, test, deploy)
Requests Kubernetes to provision agent pods
Tracks pipeline execution and logs

4.3. Kubernetes Agent Pods (Dynamic Build Agents)

Using the Jenkins Kubernetes Plugin, Jenkins dynamically spins up agent pods inside the Kubernetes cluster. Each pipeline run gets its own isolated pod, which is destroyed after completion.

Why this matters:

No long-running or idle agents
Clean environment for every build
Parallel pipelines without conflicts
Automatic scaling based on workload

Each agent pod can include multiple containers (for example: Maven, Docker CLI, kubectl), allowing different stages to run in the right environment.

4.4. Docker Image Build & Push

Inside the Kubernetes agent pod, Jenkins builds the application and creates a Docker image using the project’s Dockerfile.
The image is then pushed to a container registry such as Docker Hub, Amazon ECR, or GCR.

What happens here:

Application is compiled and tested
Docker image is built inside the agent pod
Image is tagged with version or commit hash
Image is pushed to a container registry

This ensures the same image is used across all environments.

4.5. Kubernetes Deployment

Once the Docker image is available in the registry, Jenkins deploys the application to Kubernetes using kubectl or Helm.

Deployment flow:

Jenkins applies Kubernetes manifests or Helm charts
Kubernetes pulls the image from the registry
Pods are created or updated using rolling deployments
Application becomes available via Service or Ingress

This completes the end-to-end CI/CD loop from code commit to a running application in Kubernetes.

5. How to Install and Run Jenkins on Kubernetes

Getting Jenkins up and running on Kubernetes is easier than you might think, especially with Helm, the package manager for Kubernetes. Helm simplifies complex deployments and ensures you can get a production-ready Jenkins instance quickly.

5.1 Installing Jenkins with Helm

The easiest way to install Jenkins on Kubernetes is using Helm.

Step 1: Create a Namespace for Jenkins

It’s a good practice to isolate Jenkins in its own namespace:

kubectl create namespace jenkins

Step 2: Install Jenkins

Helm is a package manager for Kubernetes that simplifies the installation of complex applications like Jenkins. To install Jenkins using Helm:

helm repo add jenkins https://charts.jenkins.io
helm repo update
helm install jenkins jenkins/jenkins --namespace jenkins

Step 3: Access Jenkins

Once installed, you can access Jenkins via the Kubernetes service. To get the admin password:

kubectl get svc --namespace jenkins

kubectl exec --namespace jenkins -it $(kubectl get pods --namespace jenkins -l "app.kubernetes.io/component=jenkins-master" -o jsonpath="{.items[0].metadata.name}") -- cat /run/secrets/chart-admin-password

Open Jenkins in your browser using the service IP and port, then log in using the retrieved admin password.

5.2 Configuring the Cloud

Once Jenkins is installed, configure it to use Kubernetes for dynamic agent provisioning:

Install the Kubernetes Plugin: Go to Manage Jenkins > Manage Plugins and install the Kubernetes Plugin. This plugin allows Jenkins to communicate with your cluster and provision agents on-demand.
Configure Kubernetes Cloud:
- Navigate to Manage Jenkins > Configure System.
- Scroll down to Cloud and click Add a new cloud > Kubernetes.
- Provide the Kubernetes API URL, Jenkins URL, and configure the Kubernetes Service Account so Jenkins can manage pods.
Create Pod Templates: Pod templates define what containers are included in each Jenkins agent pod. You can create different templates for different types of jobs, for example:
- Maven builds
- Docker image builds
- Helm deployments

6. Jenkinsfile-Based CI/CD Pipeline Implementation

With Jenkins configured to use Kubernetes, the next step is to set up CI/CD pipelines that build and deploy applications to Kubernetes.

A Jenkinsfile allows you to describe your entire pipeline — build, test, and deployment as code, making it version-controlled, repeatable, and easy to maintain.

6.1 Configuring Jenkins Pipeline for Kubernetes

A Jenkinsfile defines what steps your pipeline runs and where they run.
When using Kubernetes integration, Jenkins dynamically creates a pod-based agent for each pipeline execution.

Here’s an example of a Jenkinsfile that uses Kubernetes agents and deploys an application to a Kubernetes cluster:

pipeline {
    agent {
        kubernetes {
            label 'my-k8s-agent'
            defaultContainer 'jnlp'
            yaml '''
            apiVersion: v1
            kind: Pod
            spec:
              containers:
              - name: maven
                image: maven:3.9.6-eclipse-temurin-17
                command:
                - cat
                tty: true
              - name: kubectl
                image: bitnami/kubectl:latest
                command:
                - cat
                tty: true
            '''
        }
    }
    stages {
        stage('Build') {
            steps {
                container('maven') {
                    sh 'mvn clean install'
                }
            }
        }
        stage('Test') {
            steps {
                container('maven') {
                    sh 'mvn test'
                }
            }
        }
        stage('Deploy to Kubernetes') {
            steps {
                container('kubectl') {
                    sh 'kubectl apply -f deployment.yaml'
                }
            }
        }
    }
}

What’s happening here?

Jenkins creates a temporary Kubernetes pod for this pipeline run
The pod includes multiple containers (Maven for build/test, kubectl for deployment)
Each stage runs in the most appropriate container
After the pipeline finishes, the pod is automatically destroyed

This approach keeps builds clean, isolated, and scalable.

6.2 Automating Deployments to Kubernetes

In the pipeline above, the Deploy to Kubernetes stage uses kubectl to apply Kubernetes manifests.
These YAML files typically define resources such as:

Deployments
Services
ConfigMaps
Ingress

Because deployment happens only after successful build and test stages, Jenkins ensures that only validated artifacts reach your Kubernetes cluster.

This automation removes manual deployment steps and enables fast, consistent releases.

6.3 Deploying Applications with Helm

While kubectl apply works well, managing multiple YAML files can become difficult as applications grow.
This is where Helm becomes extremely useful.

Helm allows you to:

Package Kubernetes resources into reusable charts
Version deployments
Easily upgrade or roll back releases

Here’s a simple Jenkinsfile example that deploys an application using Helm:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Deploy to Kubernetes with Helm') {
            steps {
                sh 'helm upgrade --install myapp ./helm-chart/'
            }
        }
    }
}

With Helm:

Application configuration becomes cleaner
Environment-specific values are easier to manage
Production deployments are more predictable

7. Best Practices for Jenkins Kubernetes CI/CD Pipelines

To get the most out of Jenkins and Kubernetes, it’s important to follow a few proven best practices. These help keep your pipelines scalable, secure, and easy to maintain as workloads grow.

Use Pod Templates: Define reusable pod templates for different job types to avoid duplication.
Run Each Job in an Isolated Pod: Each Jenkins job should run in an isolated pod to ensure that builds are clean and independent.
Leverage Auto-scaling: Enable auto-scaling in Kubernetes to dynamically adjust the number of nodes based on Jenkins job demand.
Manage Secrets Securely: Use Kubernetes secrets to securely manage credentials and sensitive information.
Use Helm: Package your application as a Helm chart to simplify deployment and versioning.

8. Monitoring and Scaling Jenkins CI/CD Pipelines on Kubernetes

As CI/CD pipelines grow in complexity and usage, monitoring and scaling become critical to maintaining performance and reliability. Kubernetes makes this much easier by providing built-in scalability and strong observability integrations.

Monitoring Jenkins

Jenkins Dashboard: The Jenkins dashboard gives a quick, high-level view of pipeline executions, build history, and agent activity. It’s useful for tracking failed jobs, build durations, and overall pipeline health.
Prometheus and Grafana: For deeper visibility, Jenkins can be integrated with Prometheus and Grafana. This allows teams to monitor:
- Resource usage of Jenkins controllers and agents
- Build and job execution metrics
- Pod and node performance inside the Kubernetes cluster

Grafana dashboards make it easy to visualize trends, detect bottlenecks, and proactively address performance issues before they impact deployments.

Scaling Jenkins with Kubernetes

Kubernetes enables Jenkins to scale automatically based on workload demand. Jenkins agents can be created or destroyed as pods, allowing the CI/CD system to handle sudden spikes in build traffic without manual intervention.

By combining Kubernetes auto-scaling with proper monitoring, teams can ensure that:

Builds remain fast during peak usage
Infrastructure costs stay optimized
CI/CD pipelines remain reliable and resilient

Conclusion

Integrating Jenkins with Kubernetes creates a modern, cloud-native CI/CD platform that is scalable, efficient, and production-ready. By running Jenkins agents as Kubernetes pods, teams can dynamically provision build environments, optimize resource usage, and eliminate the limitations of static build agents.

Kubernetes features such as pod isolation, auto-scaling, and Helm-based deployments allow Jenkins pipelines to remain clean, reliable, and easy to manage as applications grow. This integration enables seamless automation—from code commits and builds to testing and deployment directly into Kubernetes clusters.

By combining Jenkins and Kubernetes, you can build CI/CD pipelines that are faster, more resilient, and ready for real-world production workloads—making continuous delivery a natural part of your DevOps workflow.

How Git Stores Files Internally to Saves Space in Your Repository

Bhagirath — Thu, 15 Jan 2026 10:40:05 +0000

Learn how Git stores files internally using snapshots, blobs, trees, and hashing to avoid duplication and save repository space efficiently.

Git is the most widely used version control system in the world, and one of the key reasons for its popularity is its highly efficient storage model. At first glance, Git appears to store a complete copy of your project every time you commit. Surprisingly, repositories remain compact even after thousands of commits.

So how does Git duplicate files while still saving disk space?

In this article, we will explore how Git stores files internally, how it avoids unnecessary duplication, and why its storage mechanism is both fast and space-efficient. By the end, you will clearly understand how Git manages file data under the hood and why it scales so well for large projects.

Overview: How Git Stores Data Efficiently

Unlike traditional version control systems such as Subversion (SVN), which store file differences between versions, Git takes a fundamentally different approach.

Git stores snapshots of the entire project state at every commit.

However, Git is smart enough not to duplicate unchanged data. If a file has not changed between commits, Git simply reuses the previously stored version instead of saving a new copy. This design enables Git to deliver:

Faster operations (branching, merging, checkout)
Reduced disk usage
Strong data integrity and reliability

1. How Git Stores Data Using Snapshots Instead of File Differences

Most version control systems track line-by-line changes over time. Git does not.

Every time you create a commit, Git records a snapshot of the entire file structure at that moment.

What Happens When Files Don’t Change?

If a file remains unchanged between commits:

Git does not store the file again
Git simply creates a reference to the existing stored content

This means Git behaves like a content-addressable filesystem, where identical content is stored once and referenced many times.

Why This Matters

This snapshot model allows Git to:

Instantly switch between branches
Perform fast merges
Avoid recalculating diffs repeatedly

2. Git Object Model: How Files Are Stored Internally

Git stores all repository data as objects inside the .git/objects directory. Each object is identified by a cryptographic hash based on its content.

There are four primary object types in Git:

Blob — File contents
Tree — Directory structure
Commit — A snapshot with metadata
Tag — Named references to commits

2.1 Blob Objects: File Content Storage

A blob (Binary Large Object) represents the raw content of a file.

Key characteristics of blobs:

Store file data only (no filename or permissions)
Identical file contents result in identical blob hashes
Stored only once, regardless of how many commits reference them

Why Blobs Enable De-duplication

If two files — or the same file across commits — have identical content:

Git stores one blob
Multiple commits point to the same blob

This is the foundation of Git’s space-saving mechanism.

You can inspect blobs using:

git ls-tree <commit-hash>

2.2 Tree Objects: Directory Structures

A tree object represents a directory in your project.

It contains:

File names
File permissions
References to blob objects
References to other tree objects (subdirectories)

Each directory in your project maps to a tree object, allowing Git to recreate the complete filesystem structure for any commit.

2.3 Commit Objects: Snapshots in Time

A commit object ties everything together.

It contains:

A reference to the root tree
Author and committer information
Commit message
Parent commit(s)

Commit Structure Example

Commit
└── Tree (Root Directory)
    ├── Blob (File 1)
    ├── Blob (File 2)
    └── Tree (Subdirectory)
        ├── Blob (File 3)
        └── Blob (File 4)

Each commit represents a complete snapshot, but most data is reused from earlier commits.

3. Inside the `.git` Directory: Git’s Internal Storage and Control System

The .git directory is the core of every Git repository. It stores all metadata, objects, and references.

3.1 `.git/objects/`

This directory stores all Git objects (blobs, trees, commits) in compressed form. Objects are named using their hash values.

3.2 `.git/refs/`

References to branches and tags live here. Each branch is simply a pointer to a commit.

3.3 `.git/index` (Staging Area)

The index tracks what will be included in the next commit. It bridges the gap between your working directory and the repository.

3.4 `.git/HEAD`

The HEAD file points to the currently checked-out branch or commit.

4. How Git Uses Hashing, Compression, and De-duplication to Save Space

Git’s efficiency comes from three core techniques.

4.1 Content-Addressable Hashing

Git computes a hash (SHA-1 by default, SHA-256 supported) for every object based on its content.

Same content → same hash
Different content → different hash

This guarantees data integrity and prevents duplication.

4.2 Object Compression

Git compresses objects using zlib, reducing disk usage while maintaining fast access.

4.3 Automatic De-duplication

Git never stores the same content twice. If a file hasn’t changed:

No new blob is created
Existing blobs are reused

This is how Git duplicates files logically without duplicating data physically.

5. From Working Directory to Commits: How Git Builds and Stores Snapshots

To fully understand how Git duplicates files while saving space, it is essential to understand the three logical areas through which every change flows: the working directory, the staging area, and the commit history. These are not just conceptual layers — they directly influence how Git creates objects and reuses existing data.

5.1 Working Directory

The working directory is the actual project folder on your local machine. It contains real files that you edit using your editor or IDE.

Key characteristics:

Files here exist outside of Git’s object database
Changes are not tracked automatically
Git does not store anything permanently at this stage

When you modify a file in the working directory:

Git detects the change
No new blob is created yet
No disk space inside .git/objects is used

This design allows Git to remain fast and lightweight while you experiment with changes.

5.2 Staging Area (Index)

The staging area, also called the index, is where Git begins its internal storage optimization.

When you run:

git add <file>

Git performs the following actions:

Reads the file content from the working directory
Computes a hash based on the content
Checks whether an identical blob already exists
Reuses the existing blob or creates a new one if needed
Records the blob reference in .git/index

Important details:

The staging area stores references, not copies
Unchanged files reuse existing blob objects
Partial staging is supported, allowing fine-grained commits

This is where Git’s de-duplication logic begins to take effect.\

5.3 Commit History

When you run:

git commit

Git creates a commit object, which includes:

A reference to a tree object
Metadata (author, timestamp, message)
A reference to the parent commit

Crucially:

Git does not duplicate file content
The new tree references existing blobs whenever possible
Only changed files produce new blobs

Each commit represents a complete snapshot, but internally, most data is shared across commits. This allows Git to maintain a full project history without ballooning repository size.

6. Exploring Git’s Internals Using Low-Level Git Commands

One of Git’s strengths is transparency. Git provides low-level commands that allow you to inspect its internal object database, making it easier to understand how files are stored and reused.

These commands are especially valuable for developers who want to understand Git beyond everyday workflows.

6.1 `git cat-file`: Viewing Raw Git Objects

The git cat-file command allows you to inspect any Git object directly.

To view a commit object:

git cat-file -p <object-hash>

This displays:

The referenced tree
Parent commit
Author and committer details
Commit message

You can also inspect blob objects to see file content exactly as Git stores it, confirming that identical content is reused across commits.

6.2 `git ls-tree`: Exploring Tree Structures

The git ls-tree command shows how a commit or tree maps to files and directories.

git ls-tree <commit-hash>

Output includes:

File permissions
Object type (blob or tree)
Object hash
File or directory name

This command clearly demonstrates how Git builds directory snapshots using tree objects that reference blob objects, without duplicating data.

6.3 `git rev-parse`: Resolving References to Hashes

The git rev-parse command helps resolve symbolic references into their actual object hashes.

git rev-parse HEAD

Use cases include:

Verifying which commit a branch points to
Debugging detached HEAD states
Understanding reference resolution

This reinforces the idea that branches and tags are lightweight pointers, not copies of data.

Conclusion: Why Git’s Storage Model Is So Powerful

Git’s ability to duplicate files logically without duplicating data physically is the cornerstone of its performance and scalability. By storing content as immutable, hashed objects and reusing them across commits, Git ensures that repositories remain fast and space-efficient — even with extensive histories.

Key Takeaways

Git stores snapshots, not file diffs
Identical file content is stored only once and reused
Blobs, trees, and commits form Git’s object model
The .git directory contains all internal data
Hashing and compression ensure integrity and efficiency

Understanding Git’s internal storage model gives you deeper confidence when working with branches, rebases, merges, and large repositories. It also explains why Git continues to outperform traditional version control systems in both speed and reliability.

Why a Good README.md Matters More Than Your Code

Bhagirath — Mon, 01 Dec 2025 10:09:45 +0000

Is your repository a ghost town? Discover why the README.md is the most critical file in your project.

The “Black Box” Problem

Imagine you are shopping for a new laptop online. You click on a product that looks promising, but the page has no photos, no spec sheet, and no price. It just has a button that says “Buy Now.”

Would you click it? Of course not. You have no idea what you are getting into.

In the world of software development, your GitHub or GitLab repository is the product page, and your README.md is the sales pitch.

Too many developers fall into the “Black Box” trap. They spend hundreds of hours writing elegant, highly optimized algorithms, pushing perfectly tested code to the src folder, and then leave the root directory empty. They assume the code speaks for itself.

Code never speaks for itself. Unless a user can understand what your project does, how to install it, and why it matters in under 30 seconds, your code effectively does not exist.

This guide moves beyond the theory. You’ll look at the architecture of documentation, visualize the user journey, and provide the exact syntax you need to turn a dead repository into a thriving open-source project.

1. The Visual Impact: Before vs. After

Let’s look at a concrete example. We have a hypothetical library called Data-Muncher, a simple Python script that cleans CSV files.

Scenario A: The “Ghost Town” (No README)

When a recruiter or developer lands on this repository, this is all they see:

📁 Data-Muncher /
├── 📁 src /
│   └── main.py
├── 📁 tests /
│   └── test_main.py
├── .gitignore
└── requirements.txt

The User Experience:

Confusion: “What does this do? Does it munch data? Is it for SQL or CSV?”
Frustration: “I have to read the source code to figure out how to run it.”
Action: The user hits the “Back” button and finds a competitor.

Scenario B: The “Professional Product” (With README)

Now, look at the exact same code, but with a structured README.md.

The directory now looks like this, but the rendering on GitHub presents a beautiful interface:

# 🦁 Data-Muncher

![Build Status](https://img.shields.io/badge/build-passing-brightgreen)
![Version](https://img.shields.io/badge/version-1.0.2-blue)
![License](https://img.shields.io/badge/license-MIT-green)

> A lightning-fast Python library to clean messy CSV files 10x faster than Pandas.

## 🚀 Features
- Removes duplicates automatically.
- Normalizes date formats (ISO-8601).
- zero-dependency architecture.

## 📦 Installation
pip install data-muncher

The User Experience:

Clarity: They know exactly what it is immediately.
Trust: The “build passing” badge proves it works.
Ease: They can copy-paste the installation command.

2. The “5-Second Rule”

In UX design, we often talk about the Time to Hello World (TT-HW). This is the time it takes for a new user to land on your repo and get the code running on their machine.

If your TT-HW is longer than 5 minutes, you lose 80% of your potential users.

The User Decision Flowchart

Below is a diagram illustrating the mental process a developer goes through when evaluating your library.

A good README removes the “No” branches from this flowchart. It streamlines the path to the “Star the Repo” outcome.

3. The Technical Anatomy of a Perfect README

A professional README isn’t just a wall of text; it is structured data using Markdown. Here are the essential components and the syntax to create them.

A. The Header and Elevator Pitch

Don’t start with “Introduction.” Start with the name and a hook.

Code Syntax:

# Project Name
**The one-line elevator pitch goes here.** *Example: "The only React Native boilerplate you will ever need."*

B. Shields (Badges)

Badges are the “Social Proof” of open source. They tell the user that the project is alive, maintained, and licensed. You don’t need complex code for this; you use markdown image links.

Code Syntax:

![License](https://img.shields.io/badge/License-MIT-green.svg)
![Downloads](https://img.shields.io/badge/downloads-10k%2Fmonth-blue)

C. The Visual Demo (Show, Don’t Tell)

If you are building a UI, a GIF is mandatory. If you are building a CLI (Command Line Interface), a screenshot of the terminal is mandatory.

Why? The human brain processes images 60,000x faster than text.

Code Syntax:

![App Demo GIF](./assets/demo.gif)
*Caption: Seeing the app in dark mode.*

D. The Quick Start (Copy-Paste Ready)

This is the most crucial technical section. Do not describe how to install it; give the command. Use “Code Fences” (triple backticks) to allow users to copy the code easily.

Bad Documentation:

“To install, you need to open your terminal and run the npm install command for our package.”

Good Documentation:

npm install my-awesome-package
# or
yarn add my-awesome-package

4. README Driven Development (RDD)

Most developers write the code first!!

Readme Driven Development (RDD) suggests that you should write the README before you write a single line of code.

How RDD Works:

Draft the README: Write down the hypothetical installation command and the API functions you wish existed.
Reality Check: As you write the README, you might realize, “Wait, this function requires 5 arguments. That is too complicated to explain.”
Refactor Design: You simplify the design before coding it, simply because explaining the complex version in the README was too hard.

5. Formatting Matters: Markdown Tricks for SEO and Readability

A wall of plain text is hard to scan. You need to use Markdown features to create hierarchy and “scannability.” Search engines (SEO) also prefer structured content.

Using Collapsible Sections

If you have a long list of configurations, use the HTML

tag within your Markdown to keep the page clean.

Code Syntax:

<details>
<summary>Click to view Advanced Configuration</summary>

| Option | Type | Default |
|--------|------|---------|
| --verbose | bool | false |
| --dry-run | bool | false |

</details>

Using Tables for Data

Don’t list arguments in paragraphs. Use tables. They are cleaner and look professional.

Code Syntax:

| Method | Description | Returns |
|--------|-------------|---------|
| `.init()` | Starts the server | `void` |
| `.stop()` | Kills the process | `boolean` |

6. The “Bus Factor” and Maintenance

Documentation is an insurance policy against the “Bus Factor.”

The “Bus Factor” is the minimum number of team members that have to be hit by a bus (or quit) before the project creates stops functioning because no one knows how it works.

If only you understand how to deploy the database, your project has a Bus Factor of 1. This is dangerous.

A good README acts as an “External Brain.” It remembers the setup steps so you don’t have to.

Essential “Maintenance” Sections to Include:

Development Setup: How to clone and run the repo locally.
Testing: How to run the test suite (npm run test).
Deployment: How the code gets to production.

7. SEO: Getting Your Repo Found

You want your project to be found on Google, not just GitHub. The README.md is the primary source of content that Google crawls.

SEO Checklist for READMEs:

Keywords in H1/H2: If your project is a “JSON Parser,” ensure those words appear in the Title and Description.
Alt Text for Images: Google cannot see images.
Bad: ![image](img.png)
Good: ![Screenshot of the JSON Parser Dashboard showing real-time metrics](img.png)
Linking: Link to your other projects or your portfolio. This creates a “backlink” structure that improves your ranking.

Conclusion: Documentation is Empathy

Ultimately, writing a good README is an act of empathy. It signals that you care about the person on the other side of the screen.

When a hiring manager looks at your portfolio, they aren’t going to clone your repo and audit your variable names. They are going to read your README.

Messy README = Messy Developer.
Structured, Clear README = Senior Engineer potential. Don’t let your brilliant code die in the dark. Light it up with a README that sells, explains, and guides.

How Kubernetes detects and restarts crashing pods automatcially

Bhagirath — Wed, 26 Nov 2025 17:35:33 +0000

A Deep Dive into the Kubelet, PLEG, and Controller Manager

One of the defining promises of Kubernetes is “Self-Healing.” When a service crashes, the platform automatically detects the failure and restores the workload without human intervention. But How does Kubernetes restart crashing pods?

Kubernetes does not technically restart pods; it replaces the containers within them. This process is managed by the Kubelet on each node, which uses the Pod Lifecycle Event Generator to monitor container states. When a container fails — indicated by a non-zero exit code, an OOMKilled signal, or a failed Liveness Probe — the Kubelet applies a restart action. This restart is throttled by an exponential backoff algorithm (doubling delay up to 300 seconds) to prevent CPU exhaustion, ensuring the system heals itself automatically.

1. The Architecture of Failure: Kubelet and PLEG

To understand detection, we must look at the Node Level. The Kubernetes Control Plane (API Server) is often too far removed to handle immediate process failures. The heavy lifting is performed locally by the Kubelet.

SyncLoop

The Kubelet runs a continuous control loop called the SyncLoop. Its job is simple: Reconcile Expected State with Actual State.

Expected State: “Run Nginx version 1.2.” (From API Server)
Actual State: “Nginx is running.” (From Runtime)

Problem with Polling

In early versions of Kubernetes, the Kubelet would constantly ask the Docker daemon, “Are my containers running?” repeatedly. With 100+ pods per node, this polling choked the CPU.

Solution: PLEG (Pod Lifecycle Event Generator)

This is the internal mechanism that makes detection fast and efficient.

Relisting: PLEG periodically relists all containers from the runtime.
Comparison: It compares the old list with the new list.
Event Generation: If it sees a change (e.g., Container ID abc changed state from Running to Exited), it generates a ContainerDied event.
Immediate Action: This event wakes up the Kubelet immediately, bypassing the standard polling cycle.

2. The Three Signals of Death

How does the runtime know a container has failed? It relies on three specific signals from the Linux Kernel and the Kubelet’s own probing logic.

A. Process Exit (Crash)

When the main process inside your container (PID 1) stops, it sends an exit code to the operating system.

Exit Code 0: The process finished successfully. (Kubernetes considers this “Completed”).
Exit Code 1–255: The process crashed or threw an error.

The Kubelet sees this non-zero code via the CRI and marks the container as Error.

B. The OOMKilled Signal (Exit Code 137)

This is the most common and misunderstood crash.

Scenario: Your application tries to allocate 512MB of RAM, but your Pod YAML limits it to 256MB.
Kernel’s Reaction: The Linux Kernel cgroups mechanism denies the memory request. The kernel invokes the OOM Killer (Out of Memory Killer), which immediately sends SIGKILL to the process.
Result: The container dies instantly with Exit Code 137 (128 + 9 for SIGKILL).

What it looks like in kubectl describe pod:

State:          Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Mon, 01 Jan 2024 12:00:00 GMT
  Finished:     Mon, 01 Jan 2024 12:05:00 GMT

If you see Exit Code 137, restarting the pod won’t fix it. You must either fix the memory leak in your code or increase the resources.limits.memory in your YAML.

C. The Liveness Probe (The Deadlock)

Sometimes, PID 1 is still running, but the application is frozen (deadlocked) or stuck in an infinite loop. The process exists, so the kernel thinks everything is fine.

This is where Liveness Probes come in. You configure the Kubelet to actively “ping” your app.

livenessProbe:
 httpGet:
 path: /healthz
 port: 8080
 initialDelaySeconds: 15
 periodSeconds: 20
 failureThreshold: 3

If the endpoint returns a 500 error or times out 3 times in a row, the Kubelet decides the application is broken. It forcefully kills the container to trigger a restart.

3. The Recovery Logic: Restart Policies

Once a failure is confirmed, the Kubelet consults the restartPolicy defined in the Pod spec.

“Always” Policy (Default) This is used for standard web servers and long-running services. Kubelet restarts the container regardless of why it stopped.

spec:
  restartPolicy: Always

“OnFailure” Policy Used for batch jobs or data processing. The container is only restarted if it crashes (non-zero exit code). If it finishes cleanly (Exit Code 0), it stays stopped.

spec:
  restartPolicy: OnFailure

“Never” Policy Used for debugging or one-off static pods. Kubernetes will never restart the container.

spec:
  restartPolicy: Never

4. The Algorithm: CrashLoopBackOff

Imagine your database is down, and your API crashes immediately upon connecting. If Kubernetes restarted your API instantly every time, it would restart 1,000 times a second, consuming all the CPU on the node.

To prevent this, Kubernetes uses an Exponential Backoff Algorithm.

Math Behind the Wait

When a container crashes repeatedly, the Kubelet inserts a delay before attempting the next restart. The delay doubles with every crash:

Crash 1: Immediate Restart.
Crash 2: Wait 10s.
Crash 3: Wait 20s.
Crash 4: Wait 40s.
…
Max Delay: 300s

When you run kubectl get pods and see status CrashLoopBackOff, it means Kubernetes is currently waiting for this timer to expire before trying again.

Resetting the Timer:
The timer doesn’t last forever. If the container starts and runs successfully for 10 minutes (configurable via minReadySeconds), Kubernetes resets the backoff counter to zero.

5. Cluster-Level Recovery: When the Node Dies

The Kubelet handles local software failures. But what happens if the physical server (Node) fails? This scenario moves the responsibility from the Kubelet to the Kubernetes Controller Manager.

Node Controller Loop:

Heartbeat Loss: Every node sends a status update to the API Server every 10 seconds.
Timeout: If the API Server receives no update for 5 minutes (default --pod-eviction-timeout), the Node Controller marks the node condition as Unknown or NotReady.
Eviction: The controller applies a NoExecute taint to the node.
Rescheduling: The ReplicaSet Controller observes that the number of running replicas has dropped below the desired count. It immediately schedules new pods on remaining healthy nodes.

6. Advanced Engineering: Startup Probes & Sidecars

As Kubernetes evolves, new features allow for more granular control over restarts.

“Slow Start” Problem
Legacy Java apps or AI models loading large weights into GPU memory can take minutes to start. A standard Liveness Probe would kill these containers before they finish booting.

The Solution: Use a startupProbe.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Logic: The probe checks every 10 seconds for 30 times (300 seconds total).
Behavior: Liveness probes are disabled until the Startup probe succeeds once.

7. How to Debug Crash Loops

When facing a crash loop, use these three commands to diagnose the root cause:

Step 1: Check the Previous Logs If the pod is currently crashing, standard logs might be empty. You need to see the logs of the previous instance that died.

kubectl describe pod <pod-name>

Look for Last State: Terminated and the Exit Code.

Step 2: Inspect the Events The “Events” section tells you why Kubelet killed it (e.g., Liveness Probe Failed, OOMKilled).

kubectl logs <pod-name> --previous

Look for the “Last State” section.

Step 3: Debug with an Ephemeral Container If the container crashes too fast to inspect, attach a debug shell to the running pod without restarting it.

kubectl debug -it <pod-name> --image=busybox --target=<container-name>

Conclusion

Kubernetes “Self-Healing” is not a single feature; it is a symphony of independent systems.

PLEG ensures crashes are detected in milliseconds.
CRI captures the specific exit codes to determine the cause.
Backoff Algorithms prevent your infrastructure from being overwhelmed by failing applications.
Controllers* handle the catastrophic loss of physical hardware.

By understanding these internals, engineers can move beyond basic troubleshooting and architect systems that are resilient to both software bugs and infrastructure failures.

How Multi-Stage Builds Make Docker Images Smaller

Bhagirath — Fri, 19 Sep 2025 13:54:19 +0000

Introduction

Docker makes it easy to package an application and its dependencies into a container image. However, the image used to build an application is not necessarily the image that should run it in production.

Building an application often requires compilers, SDKs, package managers, development dependencies, and source code. Once the application has been built, many of these components are no longer required. If they remain in the final Docker image, they increase its size and add unnecessary components to the production environment.

This is where Docker multi-stage builds provide a practical solution.

Multi-stage builds allow you to separate the build environment from the runtime environment within the same Dockerfile. The application can be built in one stage using all the required tools and dependencies, while the final stage contains only the artifacts and runtime dependencies needed to run the application.

This approach can produce significantly smaller Docker images, faster deployments, and a more minimal production environment.

In this article, we will examine how Docker images become unnecessarily large, how multi-stage builds solve this problem, how to implement them in a Dockerfile, and how to optimize the resulting image for production.

1. Why Docker Images Get Large

A Docker image can contain much more than the application that ultimately runs inside the container.

Consider a typical application build process. Before the application can run, it may require a compiler, SDK, development libraries, package managers, source code, and other build-time dependencies. These components are necessary to create the application artifact, but they usually have no role once that artifact is ready for production.

When the build and runtime environments are combined into a single Docker image, all of these components can remain in the final image.

The result looks like this:

Build Tools + Build Dependencies + Source Code + Application + Runtime Dependencies

But the production container often needs only:

Application + Runtime Dependencies

This difference is the main reason Docker images can become unnecessarily large.

Why Docker Image Size Matters

A larger image affects more than storage. Docker images are frequently pushed to container registries and pulled by CI/CD systems, servers, and Kubernetes nodes. The larger the image, the more data needs to be transferred during these operations.

Reducing Docker image size can therefore help with:

Faster image pushes and pulls
Faster deployments
Lower storage and registry usage
Smaller production environments
Reduced attack surface by excluding unnecessary build tools and packages

The underlying problem is straightforward: the environment required to build an application is often much larger than the environment required to run it.

Multi-stage builds address this by keeping the build environment separate from the final runtime image.

2. The Problem with a Single-Stage Dockerfile

A traditional Dockerfile typically uses a single base image to both build and run the application. All build tools, dependencies, source files, and runtime components are created within the same image.

For example, a compiled application may require a compiler and development dependencies during the build process. With a single-stage Dockerfile, those components remain part of the resulting image even though they are not required to run the application.

The workflow becomes:

Source Code → Build Tools → Build Dependencies → Application → Final Image

The problem is that the final image contains both the build environment and the runtime environment.

What Gets Included

A single-stage image can contain components such as:

Compilers and SDKs
Development libraries
Package managers
Source code
Build caches and temporary files
Development dependencies
The final application

Most of these components are useful only while building the application. Once the application has been compiled or packaged, they provide no value to the production container.

Why This Approach Is Inefficient

Using one image for both build and runtime creates an unnecessarily large production image. Every copy of that image pushed to a registry, stored in a cache, or pulled by a deployment environment carries those build-time components with it.

More importantly, the production environment becomes dependent on components that should never need to exist there.

The better approach is to separate the two responsibilities:

Build Stage: Contains everything required to build the application.

Runtime Stage: Contains only what is required to run the finished application.

This separation is the fundamental idea behind Docker multi-stage builds.

3. The Idea Behind Multi-Stage Builds

Docker multi-stage builds solve the problem by separating the build environment from the runtime environment.

Instead of creating the entire application inside one image, a Dockerfile can contain multiple stages. Each stage can have its own base image, dependencies, and purpose.

The first stage is typically responsible for building the application. It can contain compilers, SDKs, package managers, development dependencies, and source code without worrying about their presence in the final production image.

The final stage starts with a clean runtime image and copies only the artifacts required to run the application from the build stage.

The workflow becomes:

Source Code → Build Stage → Build Artifact → Runtime Stage → Final Image

For example, a compiled application might use a large image containing the compiler and development tools during the build.

Build Stage

Compiler + SDK + Dependencies + Source Code → Application Binary

The runtime stage then takes only the resulting binary.

Runtime Stage

Minimal Base Image + Application Binary → Production Image

The build environment is therefore not carried into the final image. Only the files explicitly copied from the earlier stage become part of the resulting production image.

This separation is what allows multi-stage builds to produce smaller and more focused Docker images while keeping the build process inside a single Dockerfile.

4. How Multi-Stage Builds Actually Work

A multi-stage Dockerfile uses multiple FROM instructions to create separate build stages. Each stage is independent and can contain only the tools and dependencies required for its specific purpose.

A typical multi-stage build has two main stages:

Build Stage

Contains the source code, compiler, SDK, and build dependencies required to produce the application.

Runtime Stage

Contains the minimal base image and only the artifacts required to run the application.

Docker allows files to be copied from one stage into another using COPY --from.

The basic flow is:

Build Stage → Build Artifact → Runtime Stage

Naming a Build Stage

A stage can be given a name using the AS keyword:

FROM <base-image> AS builder

The name makes it possible to reference that stage later in the Dockerfile.

Copying Artifacts Between Stages

The COPY --from instruction selects files from a previous stage:

COPY --from=builder <source> <destination>

Only the files explicitly copied into the final stage are included there. The compiler, source code, build dependencies, and other files that remain in the build stage are not carried into the final image.

This is the key mechanism behind multi-stage builds: build everything you need in one environment, then selectively transfer only the output required for production.

5. Before Multi-Stage Builds: A Single-Stage Dockerfile

To understand the benefit of multi-stage builds, let’s first look at a typical single-stage Dockerfile.

In a single-stage build, the same image is used to install build dependencies, compile the application, and run it in production. For a compiled application, this means the final image can contain both the tools used to build the application and the application itself.

Consider a simple Go application:

FROM golang:1.24

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o app
EXPOSE 8080
CMD ["./app"]

This Dockerfile works, but the final image is based on the Go image, which contains the Go toolchain required to compile the application.

The important point is that after go build finishes, the compiler and other build-time components are no longer needed to run the resulting binary.

However, because everything happens in the same stage, they remain part of the final image.

The resulting image therefore contains:

Go Toolchain + Build Dependencies + Source Code + Compiled Binary

Only the compiled binary and its runtime requirements are actually needed to run the application.

This is the inefficiency that multi-stage builds are designed to eliminate.

6. After Multi-Stage Builds: Separating Build and Runtime

The single-stage Dockerfile can be improved by separating the build process from the production runtime.

Instead of using the Go image for the entire application lifecycle, we can use it only to build the application. A second stage can then use a smaller runtime image and copy only the compiled binary from the build stage.

FROM golang:1.24 AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o app

FROM alpine:3.22
WORKDIR /app
COPY --from=builder /app/app .
EXPOSE 8080
CMD ["./app"]

The Dockerfile now has two separate stages.

Build Stage

The first stage uses the Go image because it provides everything required to compile the application.

It contains:

Go compiler and toolchain
Build dependencies
Source code
Compiled application

However, this stage is used only during the build process.

Runtime Stage

The second stage starts from a minimal Alpine image. It does not contain the Go compiler, source code, or other build-time components.

The COPY --from=builder instruction copies only the compiled application binary from the build stage into the runtime image.

The final image therefore contains:

Minimal Runtime Image + Compiled Application

instead of:

Go Toolchain + Build Dependencies + Source Code + Compiled Application

This is the fundamental advantage of a multi-stage Docker build: the build environment is used to create the application, but it does not need to be shipped with the application.

7. Measuring the Difference

The main goal of using multi-stage builds is to keep unnecessary build-time components out of the final Docker image. The easiest way to verify the improvement is to compare the image sizes before and after applying a multi-stage build.

For the single-stage Dockerfile, the final image is based on the Go image and therefore includes the Go toolchain and other build-time components.

With the multi-stage Dockerfile, the final image is based on a minimal runtime image and contains only the compiled application.

You can check the size of a Docker image using:

docker images

Or:

docker image ls

The comparison should look conceptually like this:

Single-stage → Larger

Multi-stage → Smaller

The exact reduction depends on the application, its dependencies, and the selected runtime image. Multi-stage builds do not remove dependencies that the application actually needs at runtime; they remove components that are required only during the build process.

The important improvement is therefore not simply that the Dockerfile has multiple stages. It is that the final stage contains only the components required to run the application.

8. Choosing the Right Runtime Image

Once the build environment has been separated from the runtime environment, the next step is choosing an appropriate base image for the final stage.

The runtime image should contain only what the application needs to run. Using a large general-purpose base image can unnecessarily increase the final Docker image size even after removing the build dependencies.

Common choices include:

Slim images: Smaller versions of standard language images with fewer packages.
Alpine: Lightweight Linux images commonly used when the application is compatible with Alpine’s environment.
Distroless: Images containing only the application and its runtime dependencies, without a traditional shell or package manager.
Scratch: An empty base image suitable for applications that can run without additional operating-system components, such as many statically compiled Go applications.

The smallest image is not always the best choice. Runtime compatibility, required libraries, debugging requirements, security considerations, and operational needs should all be considered when selecting the final base image.

The objective is simple: use the smallest practical runtime image that contains everything the application actually needs.

9. Multi-Stage Builds for Real Applications

The basic Go example demonstrates the core idea, but the same pattern is useful for applications where the build process produces artifacts that are different from the source code.

A common example is a frontend application built with Node.js. The Node.js environment may be required to install dependencies and compile the application, but the production container may only need the generated static files.

The build process can therefore be separated into two stages:

Build Stage

Node.js + Dependencies + Source Code → Production Build

Runtime Stage

Minimal Web Server + Production Build → Final Image

For example, a frontend application can be built using a Node.js image and then served using a lightweight Nginx image:

FROM node:24-alpine AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

The Node.js image is required only while building the application. The final image contains the generated frontend files and Nginx, but does not contain Node.js, npm, the source code, or the development dependencies.

This pattern is especially useful for applications where the build environment is significantly larger than the environment required to serve the final artifact.

10. Common Mistakes with Multi-Stage Builds

Multi-stage builds can significantly reduce Docker image size, but simply adding multiple FROM instructions does not automatically produce an optimized image. The final stage still needs to be designed carefully.

Copying More Than the Application Requires

The final stage should contain only the files required at runtime. Copying the entire build directory or source tree can bring unnecessary files back into the final image.

Use COPY --from to select only the required build artifacts.

Using a Large Runtime Image

Separating the build and runtime stages is only part of the optimization. If the final stage uses a large base image, the resulting image can still be unnecessarily large.

Choose a minimal runtime image that is compatible with the application.

Installing Build Dependencies in the Runtime Stage

Installing compilers, SDKs, development libraries, or other build tools again in the final stage defeats the purpose of separating build and runtime environments.

Build dependencies should remain in the build stage whenever possible.

Ignoring `.dockerignore`

Even with a multi-stage build, unnecessary files can still be sent as part of the Docker build context.

A properly configured .dockerignore should exclude files such as local dependencies, build output, Git metadata, logs, and other files that are not required during the image build.

Assuming Smaller Always Means Better

Reducing image size is useful, but the smallest possible image is not always the correct production image. Compatibility, security, observability, debugging, and operational requirements should also be considered when choosing the runtime environment.

A good multi-stage build is not simply the smallest Docker image possible. It is a minimal runtime image containing everything required to run the application and nothing that is only needed to build it.

11. Other Ways to Reduce Docker Image Size

Multi-stage builds are one of the most effective ways to separate build-time dependencies from the production image, but they are not the only way to optimize Docker image size.

Use a Minimal Base Image

Choose a base image that provides only what the application needs at runtime. A smaller and appropriate base image can significantly reduce the final image size.

Install Only Required Dependencies

Avoid installing development packages, debugging tools, or other dependencies that are not required by the application in production.

For package-based applications, install production dependencies separately from development dependencies whenever possible.

Use `.dockerignore`

A .dockerignore file prevents unnecessary files from being included in the Docker build context.

Common examples include:

.git
node_modules
Local build output
Logs
Environment-specific files
Temporary files

This reduces the amount of unnecessary data sent to the Docker daemon or build engine during the build.

Optimize Dockerfile Layering

Arrange Dockerfile instructions so that layers that change less frequently are built before layers that change frequently. This allows Docker to reuse cached layers and avoid repeating unnecessary work during subsequent builds.

These techniques complement multi-stage builds. The goal is not to rely on a single optimization, but to ensure that the final production image contains only the components required to run the application.

12. Best Practices for Multi-Stage Builds

A well-designed multi-stage Dockerfile should keep the build process reproducible while ensuring that the final image contains only what is required at runtime.

Separate Build and Runtime Responsibilities

Keep compilers, SDKs, development dependencies, and other build tools in the build stage. The final stage should focus exclusively on running the application.

Copy Only Required Artifacts

Use COPY --from to transfer only the files required by the runtime environment. Avoid copying source code, build caches, temporary files, or development dependencies into the final stage.

Use a Minimal Runtime Base

Choose a runtime image appropriate for the application rather than reusing the larger build image. Consider slim, Alpine, distroless, or scratch images where they are compatible with the application.

Optimize Dependency Installation

Install only the dependencies required for the production application. Where the ecosystem supports it, keep development dependencies out of the final runtime environment.

Take Advantage of Build Cache

Place instructions that change less frequently earlier in the Dockerfile and frequently changing instructions later. For example, copying dependency manifests before the application source code can allow Docker to reuse the dependency installation layer when only application code changes.

Keep the Final Stage Simple

The final stage should clearly show what the production container needs: the runtime base, required artifacts, configuration, and startup command.

The objective of these practices is straightforward:

Build with everything you need, but ship only what you need.

13. Conclusion

Docker multi-stage builds provide a practical way to separate the environment required to build an application from the environment required to run it.

Instead of shipping compilers, SDKs, development dependencies, source code, and other build-time components in the production image, the build stage can produce the required application artifacts and the runtime stage can contain only those artifacts and their runtime dependencies.

The result is a smaller and more focused Docker image that can reduce image transfer time, storage requirements, and unnecessary components in production.

The core principle is simple:

Build with everything you need. Ship only what you need.

For production Docker images, multi-stage builds should be considered alongside appropriate runtime base images, dependency optimization, .dockerignore, and effective Docker layer caching.

How 25 Lines of Code Actually Become a Production Feature

Bhagirath — Mon, 01 Sep 2025 07:48:52 +0000

1. Introduction

A developer opens their laptop, writes 25 lines of code, and pushes it.

To them, it feels small. A bug fix. A new field. A minor feature. Twenty-five lines shouldn’t take more than a few minutes to reason about.

But somewhere between that git push and the moment a real user sees the change, the change has to pass through a series of engineering processes: it needs to be tracked, committed, built, tested, validated, secured, packaged, deployed, exposed to users, and eventually monitored in production.

The interesting part is that no single step makes the feature production-ready. The final result comes from all of these steps working together.

What looks like “just code” is actually the smallest part of the journey. Dozens of tools. Multiple teams. Systems the developer never directly touches — but silently depends on.

This is the story of that journey — what actually happens, step by step, between a developer’s keyboard and production.

2. DevOps Lifecycle

Before looking at individual tools, it helps to see the entire journey at once.

That 25-line change doesn’t move directly from a developer’s laptop to production. It moves through a sequence of stages, with each stage answering a different question: What are we building? Can we build it? Does it work? Is it safe? Where will it run? How does it reach users? And how do we know it’s still working?

The journey looks roughly like this:

Planning → Development → Source Control → Build → Testing → Security → Infrastructure → Deployment → Networking → Monitoring → Feedback

Each stage has a purpose — and more importantly, each stage produces something the next stage depends on:

Planning defines what should be built.
Development turns that requirement into code.
Source Control records what changed.
Build creates something that can be executed.
Testing verifies that it behaves correctly.
Security checks whether it is safe to release.
Infrastructure provides where it will run.
Deployment moves the application into that environment.
Networking makes it reachable by users.
Monitoring tells us what is happening after release.
Feedback brings what we learned back into the next change.

This is where the DevOps ecosystem starts to make sense. The tools aren’t isolated pieces sitting next to each other — they exist because each stage needs to pass something forward to the next.

In the rest of this journey, we’ll take this flow apart and follow those 25 lines of code through each stage, one at a time.

3. From Requirement to Code

Every feature starts before a single line of code is written.

Someone decides it needs to exist — a product need, a bug report, a business requirement. That decision has to be captured, discussed, and broken down into something a developer can actually pick up and work on.

Jira is where that happens. The requirement becomes a ticket — scoped, prioritized, and assigned. It’s the single source of truth for what needs to be built and who’s building it.

Confluence sits alongside it, holding the why and the how. Design docs, technical decisions, API contracts, architecture notes — the context a developer needs so the ticket isn’t just a one-line instruction floating with no background.

Only once the requirement is clear does the developer open their editor and start writing those 25 lines.

When the code is ready, it doesn’t stay on the developer’s laptop — it moves into GitHub / GitLab. This is the moment the change stops being personal and becomes shared. It’s tracked, versioned, reviewed by teammates, and tied back to the original Jira ticket — so anyone looking at the commit later knows exactly what it was for and why it exists.

This is the first handoff in the chain:

requirement → task → implementation → source control

The code exists now — but it’s still just a change sitting in a branch. Nothing has verified that it actually works yet.

That’s the next stage.

4. From Code to a Verified Build

The code is written. It’s sitting in a branch on GitHub or GitLab. But “written” and “working” are two very different things — and nobody ships based on trust alone.

This is where CI (Continuous Integration) takes over. The moment that branch is pushed or a pull request is opened, tools like Jenkins, GitHub Actions, or CircleCI pick it up automatically. No one has to remember to run anything manually — the pipeline triggers itself.

But CI isn’t just “run the build.” It’s a sequence of checks, and the code has to clear all of them before it’s allowed to move forward:

Build — the code is compiled and packaged into something executable. If it doesn’t even build, nothing else matters.
Testing — tools like Selenium run automated tests to confirm the feature actually behaves the way it’s supposed to, not just that it compiles.
Code Quality — SonarQube scans the code itself: complexity, duplication, bad patterns, maintainability issues. Code can work and still be fragile.
Security — Trivy scans for known vulnerabilities — in the code, in dependencies, in the container image — before any of it gets closer to production.

If any one of these fails, the pipeline stops right there. The 25 lines don’t move forward until every check passes.

What comes out the other end isn’t just “code that runs” — it’s a verified build: compiled, tested, quality-checked, and scanned. Something a team can actually trust enough to hand off to the next stage.

And that next stage is where this verified build stops being just code — and starts becoming something that can run somewhere real.

5. From Application to Infrastructure

A verified build is still just a file sitting in a pipeline. It doesn’t run anywhere yet — it has no home. This stage is about giving it one, and it involves three distinct ideas that are easy to blur together: packaging, provisioning, and configuration.

Docker handles packaging. The application, along with everything it needs to run — dependencies, runtime, environment settings — gets bundled into a single image. That image behaves the same way whether it’s running on a developer’s laptop, a test server, or in production. This solves the classic “it worked on my machine” problem, because the machine itself is now part of the package.

But an image still needs somewhere to run. That’s infrastructure — the servers, networks, and storage the application will actually live on. This is where AWS, GCP, or Azure come in, providing the raw compute and resources.

The question is how that infrastructure gets created. Doing it by hand — clicking through a cloud console — doesn’t scale and isn’t repeatable. Terraform solves this by treating infrastructure as code: the servers, networks, and resources needed are written down in config files, and Terraform provisions exactly what’s described, every time, consistently.

Once the infrastructure exists, it still needs to be set up correctly — software installed, settings applied, services configured. That’s Ansible’s job: configuration. Terraform builds the house; Ansible furnishes it.

So the distinction is this:

Docker — package the application
Terraform — provision the infrastructure
Ansible — configure that infrastructure

The 25 lines now exist as a packaged image, with real infrastructure ready to run it. But “ready to run” and “actually running for users” are still two different things.

That’s the next stage.

6. From Infrastructure to Production

The infrastructure exists. The image is packaged. But right now, that image is just sitting there — nothing has actually placed it onto a running server, and no user has a way to reach it.

This is where Kubernetes takes over. It takes the Docker image and actually runs it — deciding which server it lands on, how many copies (replicas) should run for reliability, and what happens if one of those copies crashes. If a container dies, Kubernetes restarts it automatically. If traffic spikes, it can scale up more copies to handle the load. The application isn’t just deployed once — it’s managed, continuously, without a human watching it 24/7.

But how does that deployment actually happen — who tells Kubernetes “here’s the new version, roll it out”? That’s Argo CD. It watches the Git repository, and the moment it sees a new verified build ready to go, it syncs that change into Kubernetes automatically. This is GitOps: Git becomes the single source of truth for what should be running, and Argo CD makes sure what’s actually running always matches it. No manual deployment steps, no one SSH-ing into a server — the desired state is declared in Git, and the system converges toward it.

At this point, the application is technically live inside the cluster. But it’s still sealed off — running in an internal network Kubernetes manages, invisible to the outside world.

That’s where Nginx comes in, acting as the entry point — routing incoming requests from real users to the correct running instance of the application inside the cluster. Without it, the feature could be running perfectly and still be completely unreachable.

This is the moment those 25 lines stop being “deployed” in an abstract sense and become something a real user can actually open in a browser and use.

But shipping it isn’t the finish line.

7. Production Doesn’t Mean Finished

The feature is live. A user can open the app and actually see those 25 lines in action. It’s tempting to treat this as the finish line — but this is exactly where things start to get interesting.

Code that passed every test in a controlled pipeline can still behave differently under real traffic, real data, and real user behavior. Something might be slow under load. A dependency might fail intermittently. A memory leak might only show up after hours of runtime. None of this shows up in a test suite — it only shows up in production.

That’s why Prometheus exists. It continuously collects metrics from the running application and infrastructure — response times, error rates, CPU and memory usage, request volume — every few seconds, around the clock. It doesn’t wait for something to break; it’s always watching.

Raw metrics on their own aren’t useful to a human staring at a wall of numbers. Grafana turns that data into dashboards — graphs and visualizations that make it obvious, at a glance, whether the system is healthy or something’s drifting wrong.

But dashboards only help if someone’s actually looking at them. That’s where Slack comes in — when Prometheus detects something crossing a threshold (error rates spiking, latency climbing), an alert gets pushed straight into a team channel. The right people find out in seconds, not hours later when a user complains.

This closes the loop. What’s learned in production — a bug that only shows up at scale, a slow endpoint, an unexpected failure — feeds back into Planning, becoming the next Jira ticket, the next 25 lines, the next trip through this entire pipeline.

The feature didn’t just get released once. It’s now being watched, measured, and improved — continuously.

And that’s the real answer to the question this article started with: those 25 lines didn’t become a production feature through one step. They became one through eleven stages, dozens of tools, and a system built to make sure the loop never really closes.

DEV Community: Bhagirath

End-to-End CI/CD Pipeline Using Jenkins and Kubernetes

1. Why Integrate Jenkins with Kubernetes for CI/CD?

2. Prerequisites for Jenkins and Kubernetes CI/CD Integration

3. Jenkins Kubernetes Integration Architecture

How Jenkins and Kubernetes Work Together:

4. CI/CD Pipeline Architecture with Jenkins and Kubernetes

4.1. Git

4.2. Jenkins Controller

4.3. Kubernetes Agent Pods (Dynamic Build Agents)

4.4. Docker Image Build & Push

4.5. Kubernetes Deployment

5. How to Install and Run Jenkins on Kubernetes

5.1 Installing Jenkins with Helm

5.2 Configuring the Cloud

6. Jenkinsfile-Based CI/CD Pipeline Implementation

6.1 Configuring Jenkins Pipeline for Kubernetes

6.2 Automating Deployments to Kubernetes

6.3 Deploying Applications with Helm

7. Best Practices for Jenkins Kubernetes CI/CD Pipelines

8. Monitoring and Scaling Jenkins CI/CD Pipelines on Kubernetes

Monitoring Jenkins

Scaling Jenkins with Kubernetes

Conclusion

How Git Stores Files Internally to Saves Space in Your Repository

Overview: How Git Stores Data Efficiently

1. How Git Stores Data Using Snapshots Instead of File Differences

What Happens When Files Don’t Change?

Why This Matters

2. Git Object Model: How Files Are Stored Internally

2.1 Blob Objects: File Content Storage

Why Blobs Enable De-duplication

2.2 Tree Objects: Directory Structures

2.3 Commit Objects: Snapshots in Time

3. Inside the .git Directory: Git’s Internal Storage and Control System

3.1 .git/objects/

3.2 .git/refs/

3.3 .git/index (Staging Area)

3.4 .git/HEAD

4. How Git Uses Hashing, Compression, and De-duplication to Save Space

4.1 Content-Addressable Hashing

4.2 Object Compression

4.3 Automatic De-duplication

5. From Working Directory to Commits: How Git Builds and Stores Snapshots

5.1 Working Directory

5.2 Staging Area (Index)

5.3 Commit History

6. Exploring Git’s Internals Using Low-Level Git Commands

6.1 git cat-file: Viewing Raw Git Objects

6.2 git ls-tree: Exploring Tree Structures

6.3 git rev-parse: Resolving References to Hashes

Conclusion: Why Git’s Storage Model Is So Powerful

Key Takeaways

Why a Good README.md Matters More Than Your Code

The “Black Box” Problem

1. The Visual Impact: Before vs. After

Scenario A: The “Ghost Town” (No README)

Scenario B: The “Professional Product” (With README)

2. The “5-Second Rule”

The User Decision Flowchart

3. The Technical Anatomy of a Perfect README

A. The Header and Elevator Pitch

B. Shields (Badges)

C. The Visual Demo (Show, Don’t Tell)

D. The Quick Start (Copy-Paste Ready)

4. README Driven Development (RDD)

How RDD Works:

5. Formatting Matters: Markdown Tricks for SEO and Readability

Using Collapsible Sections

Using Tables for Data

6. The “Bus Factor” and Maintenance

Essential “Maintenance” Sections to Include:

7. SEO: Getting Your Repo Found

SEO Checklist for READMEs:

Conclusion: Documentation is Empathy

How Kubernetes detects and restarts crashing pods automatcially

1. The Architecture of Failure: Kubelet and PLEG

SyncLoop

Problem with Polling

Solution: PLEG (Pod Lifecycle Event Generator)

3. Inside the `.git` Directory: Git’s Internal Storage and Control System

3.1 `.git/objects/`

3.2 `.git/refs/`

3.3 `.git/index` (Staging Area)

3.4 `.git/HEAD`

6.1 `git cat-file`: Viewing Raw Git Objects

6.2 `git ls-tree`: Exploring Tree Structures

6.3 `git rev-parse`: Resolving References to Hashes

Ignoring `.dockerignore`

Use `.dockerignore`