CI/CD Simulation Platform

Deploy Simulator

A lightweight Python application that mimics real-world deployment pipelines — generating synthetic deploy records, tracking running jobs, computing analytics, and exposing everything through a REST API and live browser dashboard.

View on GitHub Run locally →
4
Microservices
REST
FastAPI backend
Live
Dashboard UI
0
External DB
01 — About

What it does

Deploy Simulator models the lifecycle of CI/CD deployments — from a running job through completion — with per-service metrics, anomaly detection, and success-rate tracking. Everything runs in a single process with no external database.

02 — Architecture

High-level architecture & tech stack

One Uvicorn process hosts the FastAPI API, background generator thread, in-memory store, metrics engine, and static dashboard — all same-origin.

Browser index.html + CSS fetch() polling FastAPI · App/main.py REST Routes Static Files DeploymentOps Queue + id index + RLock MetricOps P95 · anomalies DummyGenerator daemon thread Uvicorn ASGI server every 10s → add running deployment

Tech stack

🐍
Python 3
Runtime & concurrency
⚡
FastAPI
REST API & validation
🚀
Uvicorn
ASGI HTTP server
📐
Pydantic v2
Deployment schema
🧵
threading
Background generator
🌐
Vanilla JS
Dashboard — no build step

Core modules

  • models.py Pydantic Deployment record — id, service, status, duration, timestamp, commit SHA
  • deployment_ops.py In-memory queue & index; add running jobs, complete with computed duration
  • metric.py P95 per service, anomaly detection, success-rate analytics
  • dummy_generator.py Weighted random deploys every 10s; completes after simulated duration
  • main.py FastAPI lifespan, routes, structured error responses
  • static/ Live dashboard with auto-refresh tables & generation toggle
03 — Workflow

How deployments flow through the system

Select a workflow below to see how data moves between the browser, API, store, metrics engine, and background generator.

Generator create running running duration = 0 sleep(duration) simulated work complete PATCH or internal success / fail / rolled-back duration computed MetricOps.record_completed() runs on every terminal status

Running-first model: Deployments enter the store with status running and zero duration. After a simulated wait, the generator (or a PATCH /deployments/{id} call) finalizes them with a terminal status and a duration derived from timestamps.

Toggle ON POST /deployments/start DummyGenerator Thread loop add_deployment repeats every 10 seconds until POST /deployments/stop

Background generation: Starting the generator spins a daemon thread that enqueues a new running deployment every 10 seconds. Stopping sets a thread event; the id counter persists across start/stop cycles within the same server session.

Browser dashboard (App/static/index.html) GET /deployments/running every 5s GET /deployments/latest every 5s GET /success-rate every 10s GET /p95 on demand Same-origin fetch — no separate frontend server required

Live UI: The dashboard polls running and completed deployments automatically, refreshes success rate on a slower interval, and loads P95 / anomaly data on button click — all against the same FastAPI process.

Deployment completes P95 duration 95th percentile per service needs ≥ 5 completed Anomaly detection duration > avg(last 5) + 2×SPREAD SPREAD = 5 seconds Success rate success / total × 100 per-service counters MetricOps ← called from DeploymentOps.complete_deployment()

Metrics on completion: Every finalized deployment triggers MetricOps.record_completed(), which updates per-service statistics, checks for duration anomalies against recent history, and increments status counters used by the success-rate endpoint.