CI/CD: full stack pipelines

A modern software pipeline is no longer one conveyor belt. It is more like an airport: one system checks in the code, another inspects the bags, another loads the plane, and another watches the runway after takeoff. (docs.github.com) Continuous integration means every code change gets built and tested automatically instead of waiting for a Friday release window. Continuous deployment means the same automation can publish that change after the checks pass. (docs.github.com) GitHub usually sits at the front of that line because it is where the repository, pull requests, and commit history already live. A push to the repository becomes the event that wakes up the rest of the pipeline. (docs.github.com) Jenkins is often the worker that picks up that event and runs the jobs in order. Jenkins Pipeline lets teams define those jobs in a `Jenkinsfile`, so the build steps live in version control next to the application code. (jenkins.io) Docker solves the “works on my machine” problem by packing the app and its tools into a container image. Jenkins can run stages inside Docker images, which keeps the build environment consistent across laptops, test servers, and production. (jenkins.io) (docs.docker.com) Kubernetes is the traffic controller after that container image is built. Its job is to deploy, scale, and manage those containerized applications across a cluster instead of on one long-lived server. (kubernetes.io) Argo CD changes how that deployment happens by treating Git like the source of truth for the cluster. Its controller continuously compares what is running in Kubernetes with what the Git repository says should be running, then syncs the cluster back to that desired state. (argo-cd.readthedocs.io 1) (argo-cd.readthedocs.io 2) That is why stacks like GitHub to Jenkins to Docker to Kubernetes to Argo CD keep showing up in real teams. Jenkins builds the artifact, but Argo CD handles delivery by watching configuration changes in Git instead of having the build server push straight into the cluster. (argo-cd.readthedocs.io) (jenkins.io) Security checks now sit inside that path instead of after it. OWASP Dependency-Check looks at third-party libraries and matches them against publicly disclosed vulnerabilities, which catches the common case where the app code is fine but one package inside it is not. (owasp.org) (devguide.owasp.org) SonarQube adds a different layer by scanning the source code itself for quality and security issues before release. Its Software Composition Analysis features also inspect dependencies, so teams can gate a build on both code smells and risky packages. (docs.sonarsource.com) Trivy pushes the scan further down the line by checking container images, repositories, infrastructure-as-code files, and even Kubernetes clusters for vulnerabilities and misconfigurations. That matters because a clean codebase can still ship an unsafe image if the base package or deployment manifest is wrong. (trivy.dev) Prometheus is the system that watches what happens after deployment by scraping metrics endpoints and storing time-series data. Kubernetes documents this as a common metrics pipeline, because cluster components already expose metrics in Prometheus format. (kubernetes.io) (prometheus.io) Grafana is the dashboard layer on top of that metrics store. Prometheus collects the numbers, and Grafana turns those numbers into charts, alerts, and incident views that humans can actually read at 3 a.m. (prometheus.io) (grafana.com) The developer post making the rounds is useful because it shows the real shape of modern delivery: no single product does source control, builds, security, deployment, and observability equally well. The pipeline works because each tool owns one job, and Git ties the whole chain together from commit to running service. (argo-cd.readthedocs.io) (docs.github.com)