Production-Like DevOps Platform integrating CI, CD, Monitoring and Logging

Abhishek Jha — Fri, 16 Oct 2026 17:03:16 +0000

I built an end-to-end DevOps platform that covers the full life of a code change: from a git push, through automated testing and deployment, to metrics, alerts and logs for the running application in Kubernetes. Deploying by hand is slow and error-prone, and knowing whether a release is healthy is a separate problem, so this project removes every manual step between a commit and a live, observable application.

The pipeline starts with GitHub Actions. On every pull request it runs automated tests, builds a Docker image, and scans it with Trivy, blocking the change if a critical vulnerability turns up. When a change is merged to main, the image is tagged with the commit SHA and pushed to GitHub Container Registry, and a final job commits the new tag into the Kubernetes manifests. Argo CD watches that Git repository and keeps my local Kubernetes cluster (Docker Desktop) in sync with it, so deployment became a pull-based GitOps flow with no manual kubectl, and with self-healing that undoes any manual change made to the cluster.

For visibility I added a monitoring and logging stack, all deployed through Argo CD as well. The app exposes request counts, request durations and runtime metrics, which Prometheus scrapes and Grafana shows on a golden-signals dashboard (traffic, errors, latency and saturation). Alert rules flag a high error rate, slow requests, high memory use or an app that is down. For logs, the app writes structured JSON with a request ID on every line. Grafana Alloy ships them to Loki, so I can move from a spike on a metrics panel to the exact log lines behind it, and follow a single request by its ID.

The most useful part was working through the problems a real pipeline throws up. A pinned security-scan action I had chosen no longer resolved after a supply-chain incident, the scan caught a critical CVE bundled inside npm in the base image (fixed by updating the base and removing npm from the runtime image), the container registry package was private by default, and a bot job failed because it ran git pull --rebase before committing. I also replaced the end-of-life Promtail with Alloy. This project taught me how CI, CD and observability fit together, and how real delivery pipelines are built beyond “docker build and run.”

Building an End-to-End CI/CD Pipeline with Jenkins, Docker & Kubernetes

Abhishek Jha — Sun, 16 Aug 2026 13:42:41 +0000

Source Code:- https://github.com/AbhishekJha29/CI-CD-Pipeline-with-Jenkins-Docker-Kubernetes

I built an end-to-end CI/CD pipeline to automate the full journey from code push to a running application in Kubernetes, handling the real-world gap between "code is written" and "code is actually deployed." Manual deployment is error-prone and slow, so this project focuses on removing every manual step between a developer's commit and a live, updated application in the cluster.

The system connects a GitHub repository to a self-hosted Jenkins server via webhooks, so every push automatically triggers the pipeline. Jenkins installs dependencies, runs automated tests, builds a Docker image tagged with the build number, and pushes it to Docker Hub. Since Jenkins runs in its own container without Docker or kubectl installed by default, I built a custom Jenkins image using the Docker-outside-of-Docker pattern, giving Jenkins controlled access to the host's Docker daemon so it can build and manage images as part of the pipeline itself.

To test it properly, I deployed the application to a local Kubernetes cluster (Minikube), verified it was reachable, then made deliberate code changes and pushed them to simulate real development cycles. The final pipeline stage runs kubectl to update the live deployment with the newly built image, and I validated each rollout by watching the pods terminate and restart with the new version, confirming the deployment actually updated rather than just appearing to.

To make it more production-oriented, I containerized the whole pipeline environment rather than relying on locally installed tools, and worked through the networking and credential-handling issues that come with running Jenkins, Docker, and Kubernetes as separate, isolated environments — including cross-container networking, portable kubeconfig generation, and secure credential storage in Jenkins rather than hardcoding them. This project helped me understand CI/CD internals, container orchestration, webhook-driven automation, and how real deployment pipelines are designed beyond just "docker build and run."

DEV Community: Abhishek Jha

Production-Like DevOps Platform integrating CI, CD, Monitoring and Logging

Building an End-to-End CI/CD Pipeline with Jenkins, Docker & Kubernetes