Cloud Native Configuration Management

Cloud Native Configuration Management is a full-stack configuration governance workspace for project, factory, environment, template, override, export, and change-history workflows.

The repository is organized as a single workspace with a React frontend, a Spring Boot backend, PostgreSQL persistence, automated tests, coverage reports, and SonarQube quality analysis.

Live Demo

• GCP frontend: https://mcmp-frontend-service-366904866748.europe-west1.run.app/
• Vercel frontend: https://cloud-native-steel.vercel.app/

The GCP deployment demonstrates the cloud-hosted frontend path. The Vercel deployment is kept as an alternate frontend hosting target for comparison and fallback.

Project Overview

The application helps teams manage reusable configuration templates and project-specific overrides across deployment scopes.

Core capabilities:

• user registration, login, JWT authentication, and role-aware screens;
• configuration template creation, editing, inspection, import, export, and deletion;
• project, factory, and environment scope browsing;
• project scope configuration preview with inherited template values and overrides;
• change-request and version-history support for configuration changes;
• backend service tests and frontend component/page tests;
• SonarQube quality gate validation with frontend and backend coverage.

Repository Structure

.
├── backend/                 Spring Boot API, domain logic, persistence, tests
├── frontend/                Vite React UI, Vitest tests, frontend coverage
├── deploy/                  Nginx and Docker Compose deployment references
├── docs/                    Shared project documentation
├── sonar-project.properties Root aggregate SonarQube scan configuration
└── README.md                Main project guide

Important entry points:

• frontend/src: React application source
• frontend/tests: frontend tests
• backend/src/main/java: backend application source
• backend/src/test/java: backend tests
• sonar-project.properties: canonical SonarQube scan configuration

Architecture

Local development runs three main services:

Browser
  -> Vite dev server / frontend static build
  -> Spring Boot backend API
  -> PostgreSQL database

The production-oriented deployment model is stateless at the backend layer:

Users
  -> DNS / HTTPS
  -> Load Balancer or Reverse Proxy
      -> Frontend static app
      -> Backend API replica pool
          -> PostgreSQL / managed database

The backend uses JWT-based authentication and stores source-of-truth data in PostgreSQL, so backend replicas can be placed behind a load balancer without sticky sessions.

Deployment references are in deploy/README.md.

Requirements

• Node.js 20.19+
• npm
• Java 21+
• Maven
• PostgreSQL 15+, or Docker for local PostgreSQL
• Optional: local or online SonarQube / SonarCloud access

Default local ports:

Frontend:   http://127.0.0.1:5173
Backend:    http://127.0.0.1:8080
PostgreSQL: localhost:5432
SonarQube:  http://localhost:9000, if running locally

Quick Start

1. Start PostgreSQL

If PostgreSQL is not already available locally, start a Docker container:

docker run --name cloud-native-postgres \
  -e POSTGRES_USER=cloudnative \
  -e POSTGRES_PASSWORD=cloudnative \
  -e POSTGRES_DB=cloud_native_db \
  -p 5432:5432 \
  -d postgres:15

If the container already exists:

docker start cloud-native-postgres

The backend defaults are:

DATABASE_URL=jdbc:postgresql://localhost:5432/cloud_native_db
DATABASE_USERNAME=cloudnative
DATABASE_PASSWORD=cloudnative
QUICK_ADMIN_PASSWORD=optional local quick-login password

If your database runs on another port, export the variables before starting the backend.

2. Start Backend

cd backend
mvn spring-boot:run -Dspring-boot.run.profiles=dev

The backend runs on http://127.0.0.1:8080.

Flyway applies database migrations on startup. The seed data includes template types, sample projects, factories, environments, and project scope template selections.

Health check:

GET http://127.0.0.1:8080/api/health

3. Start Frontend

cd frontend
npm install
npm run dev

The frontend runs on http://127.0.0.1:5173.

Application Flow

1. Open http://127.0.0.1:5173.
2. Register or log in.
3. Use Search to search configurations and templates.
4. Use Templates to manage reusable configuration fragments.
5. Use Projects to inspect project scope configuration by project, factory, and environment.
6. Use export/import screens to move configuration data through supported formats.

The main project inspection flow is:

Project List -> Factory List -> Environment List -> Templates Used -> Effective Config Preview

The clone-source preview flow supports selecting a base project/factory/environment and optionally mixing individual template sources from other scopes before review.

Testing And Coverage

Frontend

cd frontend
npm run test
npm run test:coverage

Coverage output:

frontend/coverage/lcov.info
frontend/coverage/coverage-summary.json

The LCOV file is the frontend coverage input used by SonarQube.

Backend

cd backend
mvn clean verify

This runs backend tests and generates JaCoCo coverage:

backend/target/site/jacoco/index.html
backend/target/site/jacoco/jacoco.xml

The XML report is the backend coverage input used by SonarQube.

The PostgreSQL/Testcontainers integration test is tagged as integration and skipped by default. To include it:

cd backend
mvn verify -Dexcluded.test.tags=

More backend setup details are in backend/README.md.

SonarQube Quality Gate

The canonical SonarQube project is the root aggregate project:

cloud-native

Run the scanner from the repository root after generating both frontend and backend coverage reports:

cd frontend
npm run test:coverage

cd ../backend
mvn clean verify

cd ..
npx @sonar/scan \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=$SONAR_TOKEN

The root scan reads sonar-project.properties, including:

frontend/coverage/lcov.info
backend/target/site/jacoco/jacoco.xml

Use the root cloud-native project for final quality gate evidence. Standalone project keys such as cloud-native-frontend and cloud-native-backend have separate baselines and issue history, so they can produce different results unless maintained intentionally.

Detailed SonarQube notes, online-scan requirements, and troubleshooting are in docs/quality-and-sonarqube.md.

Code Quality Policy

The project uses a conservative coverage and quality strategy:

• test user-facing frontend flows and backend business logic
• exclude low-value bootstrap, DTO, repository, controller, enum, static data, and framework-wiring files from coverage KPIs where appropriate
• avoid committing generated output such as coverage/, target/, .scannerwork/, and dist/
• treat security hotspots as review items that require either remediation or a clear explanation.

Current local quality evidence should be regenerated from the commands above instead of relying on committed reports.

Security Scanning

Dependency vulnerability scanning is documented as a manual workflow in docs/security-scanning.md.

Common commands:

cd frontend
npm audit --audit-level=high

cd ../backend
mvn org.owasp:dependency-check-maven:check

These dependency scans complement application security tests for JWT authentication, role guards, and protected backend endpoints.

Deployment

Deployment references live in deploy/README.md:

• deploy/nginx.production.conf: production-oriented reverse proxy template;
• deploy/production-like/: Docker Compose stack with frontend, backend replicas, reverse proxy, and PostgreSQL;
• deploy/demo/: local demo stack with Nginx and scaled backend replicas.

The backend health endpoint for load balancers and uptime checks is:

GET /api/health

Documentation Guide

• backend/README.md: backend setup, PostgreSQL, Flyway, tests, and coverage
• deploy/README.md: deployment topology and production-like local stack
• docs/quality-and-sonarqube.md: coverage, SonarQube, online scan, and Quality Gate guidance
• docs/security-scanning.md: manual dependency vulnerability scanning

CI

GitHub Actions runs separate frontend and backend jobs from .github/workflows/ci.yml.

The CI workflow currently covers:

• frontend dependency install, tests, and build;
• backend Maven tests;
• fast feedback for pull requests and branch updates.

License

This project is licensed under the MIT License.