vishnuofficial164/devops-cicd-pipeline

Purpose and Scope

This repository is infrastructure for a minimal end-to-end CI/CD demonstration: source changes flow from GitHub through Jenkins, are packaged as a Docker image, published to Docker Hub, and deployed to Kubernetes. It contains deployment automation and manifests, not application source code.

CI/CD Entry Point

Jenkinsfile is the primary automation entry point. Jenkins is expected to trigger from GitHub changes, check out repository contents, build the application/image, push an image to Docker Hub, and apply or update Kubernetes resources. Jenkins therefore requires GitHub access, Docker build capability, Docker Hub credentials, and Kubernetes cluster credentials.

Container Build Boundary

Dockerfile defines the application container artifact consumed by deployment. It is the boundary between the build environment and runtime: Jenkins builds this image, Docker Hub stores it, and Kubernetes pulls it. The repository does not expose application source files, so the Dockerfile determines what build context and runtime process are available.

Kubernetes Workload Control Plane

deployment.yaml defines the Kubernetes Deployment, the desired application state, and its container image reference. Kubernetes creates and reconciles the underlying ReplicaSet and Pods; those generated resources are not separately defined in this repository. Image updates from the pipeline are deployed through this workload boundary.

Network Exposure

service.yaml defines the stable Kubernetes Service in front of the Deployment’s Pods. The documented access model is NodePort, allowing browser clients to reach the workload through a cluster node address and exposed port. Correct Service selectors must align with the Pod labels defined by deployment.yaml.

Namespace Isolation

namespace.yaml defines the Kubernetes namespace used to scope deployed resources. Deployment ordering must ensure this namespace exists before applying namespaced workload and Service manifests. The Jenkins deployment step is responsible for applying these manifests to the intended cluster/context.

Primary Flow and External Systems

Control flow is: GitHub push → Jenkins pipeline (Jenkinsfile) → Docker build (Dockerfile) → Docker Hub image registry → Kubernetes apply (namespace.yaml, deployment.yaml, service.yaml) → Deployment/ReplicaSet/Pods → NodePort Service → browser. Material external dependencies are GitHub, Jenkins, Docker/Docker Hub, and a Kubernetes cluster; Linux/Git support the execution environment.