flight-reservation-devops: The Repo That Turns Jenkins Into a GitOps Trigger

A flight booking app is the excuse. The real lesson is how CI, Git, Kubernetes, and Argo CD split responsibility into a clean, auditable release pipeline.

9 min read • View on GitHub • More from prajwalpatil07

A wide editorial scene of a DevOps release path on a white background. On the left, a Jenkins pipeline hands a Git commit baton into a Kubernetes manifest, and on the right Argo CD watches the repo and rolls the change into a private cluster. It explains that Git is the control point, not a deployment script. — The repo's core trick is not faster deployment. It is moving deployment intent into Git, where Argo CD can reconcile it.

Key Takeaways

This repo is memorable because Jenkins stops at Git, which turns the manifest into the release contract and Argo CD into the applier.
The flight app is intentionally plain, so the reader can see the delivery system instead of getting distracted by business complexity.
The infrastructure is more production-shaped than most demos because Terraform, Ansible, EKS, RDS, and SonarQube are wired as a coherent stack.
The frontend gets a simpler S3 path on purpose, which shows pragmatic boundaries rather than forcing every component through Kubernetes.

The clever part here is not the flight booking UI. It is the release model. Jenkins builds, tests, scans, then writes the new image tag back into Git. Argo CD watches that repository, sees the changed desired state, and reconciles the cluster.

Why Jenkins Stops at Git

The important boundary is simple. CI computes the release, Git declares it, and CD applies it.

Flight-Reservation-DevOps project is a comprehensive guide to understanding and implementing a complete Devops lifecycle for a web application.

Prajwal Patil, Project Creator/DevOps Engineer · Flight-Reservation-DevOps Project Documentation

That README line is broad, but it points at the right thing. This repo is not trying to sell a flight product. It is trying to make a full delivery lifecycle legible in one place.

The Flight App Is the Decoy

The application layer is deliberately ordinary. A Spring Boot backend handles booking logic, a React frontend handles the UI, and a check-in service adds just enough domain shape to feel real. The point is not novelty. The point is to keep the DevOps story visible.

A close editorial scene of a handwritten Kubernetes manifest being edited inside Git. One hand labeled Jenkins changes an image tag in YAML while another hand labeled Argo CD lifts the updated file toward a cluster. It explains how the pipeline deploys by changing desired state, not by calling kubectl directly. — The repo's most important move happens in one file. Change the image tag, and the rest of the system follows.

What Lives Where

Layer	What lives there	Why it matters
Application	Spring Boot, React, check-in service	Keeps the business example small enough to understand
Infrastructure	Terraform, Ansible, AWS modules	Makes the repo behave like a real platform build
Orchestration	Jenkins, Argo CD, Kubernetes manifests	Separates release computation from cluster reconciliation
Observability and quality	SonarQube, Prometheus, Grafana	Adds the day-two discipline most demos skip

The stack is broad, but the boundaries are clean. Java, JavaScript, HCL, YAML, and shell each do one job. That matters because the repo is teaching composition, not tool collecting.

Inside the infra modules

The Terraform layout reads like a production sketch. VPCs use public and private subnets, NAT keeps private resources reachable without exposing them, EKS runs the compute plane, and RDS holds application data away from the public edge. That is not just cloud decoration. It is a sane shape for a system that expects to grow.

Choice	What a toy demo does	What this repo does
Networking	Single flat cluster	Public and private subnet split with NAT
Data	In-memory or local DB	Managed RDS for app data
Provisioning	Ad hoc scripts	Terraform modules plus Ansible setup
Release	kubectl from CI	GitOps handoff through Argo CD

The Frontend Cheats, and That Is Fine

The frontend deployment is the pragmatic exception that proves the rule. Instead of forcing static assets into Kubernetes, the pipeline builds the React app and syncs the output to S3. That keeps the frontend simple, cheap, and easy to reason about.

Path	Backend	Frontend
Artifact	Container image	Static assets
Deployment target	EKS via Argo CD	S3 website hosting
Release trigger	Manifest tag change in Git	S3 sync after build
Operational burden	Higher	Lower

Security Is Stateless on Purpose

The backend security setup is what you want in a modern API. JWT auth makes sessions stateless, the security filter chain permits only the flows that need to be public, and role checks gate administrative actions. CSRF is disabled because the API is token driven, not browser session driven.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.csrf(csrf -> csrf.disable())
        .sessionManagement(sm -> sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/auth/**").permitAll()
            .requestMatchers("/admin/**").hasRole("ADMIN")
            .anyRequest().authenticated());
    return http.build();
}

That is a useful signal. The repo is not pretending that infrastructure alone equals maturity. It also has application security choices that match the delivery model.

The Toolchain Feels Enterprise Because It Is

SonarQube, Nexus, Prometheus, Grafana, Jenkins, Ansible, and Terraform are not there as logo wallpaper. They create the same sort of boring, durable guardrails used in many internal platform teams: code quality checks, artifact handling, metrics, and server bootstrap. The SonarQube setup even includes kernel tuning, which is the kind of detail that separates a demo from something that has at least touched real operations.

This project is designed for beginners to intermediate DevOps engineers to understand how different tools work together to automate the entire software development lifecycle.

Prajwal Patil, Project Creator/DevOps Engineer · End-to-End DevOps Project: Flight Reservation System

Signal	Minimal demo	This repo
Quality gate	Usually skipped	SonarQube included in the flow
Artifact management	Often omitted	Nexus is part of the stack
Monitoring	Optional screenshots	Prometheus and Grafana included
Host bootstrap	Manual	Ansible playbooks and system tuning

How It Compares to the Usual Demos

Compared with Sock Shop, Online Boutique, example-voting-app, and spring-petclinic-cloud, this repo is smaller and less theatrical. That is its advantage. It is closer to the kind of stack a single engineer can actually reproduce, and closer to the enterprise patterns many teams want to learn without inheriting a monster.

Repo	Scope	Primary goal	Deployment style	Beginner friendliness	Enterprise realism
flight-reservation-devops	Focused	Teach a full GitOps delivery pipeline	Jenkins to Git to Argo CD	High	High
Sock Shop	Broad	Show microservices at scale	Kubernetes showcase	Medium	Medium
Online Boutique	Broad	Demonstrate cloud-native patterns	GKE showcase	Medium	Medium
example-voting-app	Narrow	Teach containers and orchestration	Docker and swarm style	High	Low
spring-petclinic-cloud	Focused	Show Spring cloud-native design	Cloud-native service mesh style	Medium	Medium

The repo wins by being teachable and specific. It does not try to be the biggest demo on the internet. It tries to be the clearest explanation of how a modern release pipeline fits together.