gowthamganesanamibikapthy/cloud-go-live-command-center

Purpose and Runtime

This repository is a lightweight Streamlit command-center simulator for managing an insurance-core-system go-live. Its primary entry point is app.py, launched with streamlit run app.py. Python dependencies are defined in requirements.txt.

Dashboard Application

app.py implements the single-page interactive UI and its operational workflows:

• Seven-phase go-live gate progression from T-30 through closeout.

• Resource call-sheet and active-shift management.

• Incident-command message generation for email and Slack.

• Rollback-trigger simulation and fallback checklist display.

The application is stateful during a Streamlit session and persists selected operational state locally.

Session Persistence Boundary

The dashboard saves and restores gates, active shifts, and latest run data through local JSON-backed session storage:

• Default session state is written to session_state.json at runtime.

• Named session records are stored in a runtime-created sessions/ directory.

• Persistence controls are part of the Streamlit workflow in app.py.

This is local filesystem persistence rather than a database or remote state service.

Incident and Rollback Control Flow

User actions in app.py drive the core operational sequence:

1. Operators update phase gates and resource shifts.

2. Incident workflows generate communication templates, mock ticket identifiers, and timing windows.

3. A failed task in the rollback simulator activates an automated fallback checklist.

4. The current operational state can be saved for recovery or later replay.

The UI is therefore both presentation layer and control/orchestration layer; no separate backend service is represented in the tree.

Integration and Deployment Assets

The integrations/ directory contains deployment and observability reference artifacts rather than application modules:

• integrations/otel-config.yaml defines OpenTelemetry collector configuration.

• integrations/datadog-daemonset.yaml provides Datadog Kubernetes agent deployment material.

• integrations/helm_values.yaml supplies Helm deployment values.

• integrations/teamcity_build.xml represents TeamCity CI build configuration.

• integrations/SECURITY_GUIDE_GUIDEWIRE.md documents Guidewire-oriented security considerations.

These assets indicate intended integration with Kubernetes, Helm, Datadog, OpenTelemetry, TeamCity, and Guidewire environments, while the local dashboard itself remains a standalone Streamlit process.

Automation and Operational Interfaces

Repository automation supports release and repository/deployment workflows:

• .github/workflows/release.yml defines GitHub Actions release automation.

• create_and_push_repo.py supports repository initialization/push operations.

• deploy_and_pr.py supports deployment and pull-request automation.

• tools/mock_webhook_server.py provides a local mock boundary for webhook-driven integration testing or demonstrations.

• WEBHOOK_RUNBOOK.md is the operational reference for webhook handling.

Key Architectural Boundaries

The primary boundaries are: Streamlit UI/state in app.py; local JSON/session filesystem persistence; optional mocked webhook interaction in tools/mock_webhook_server.py; and externally consumed infrastructure templates under integrations/. There is no evidence of a production API, database, identity provider, message broker, or real ticketing/Slack integration in the provided repository structure.