microsoft/release-manager-assistant

1. Overall shape

This repo is a containerized, multi-service AI assistant for release management. It is split into a browser UI, a real-time session layer, an orchestration/agent backend, an MCP-based tool server, and Azure infrastructure code that deploys the whole stack.

2. User-facing frontend

src/frontend/react-app is a React/Vite single-page app served as static content. It contains the chat UI, message rendering, and input controls. Its job is limited to presentation and user interaction; it does not contain business logic or direct integrations with Jira/Azure DevOps.

3. Real-time session boundary

src/backend/services/session_manager is the WebSocket-facing service. It sits between the UI and the AI backend, managing client connections, conversation state, and message flow. The presence of client_manager, conversation_handler, and websocket_handler indicates it is the gateway for live chat sessions rather than the reasoning engine itself.

4. Message/state infrastructure

The session layer uses shared utilities for queues, Redis messaging, and thread-safe caches from src/backend/common/utilities. The repo and README point to Redis as the backing service for session management and message queuing, so ephemeral conversation state is externalized rather than embedded in the frontend or orchestrator.

5. Orchestrator as the reasoning core

src/backend/services/orchestrator is the main AI workflow service. It contains the agent coordinator, planner, fallback, final-answer generation, and domain agents. This is where user intent is interpreted and routed to the right capability, rather than directly answering in one model call.

6. Agent specialization

The orchestrator splits work across agents such as planner_agent, jira_agent, azure_devops_agent, visualization_agent, and fallback_agent. This creates a clear internal boundary: planning and routing are separate from system-specific retrieval/update logic and separate again from response synthesis.

7. External system integrations

Jira integration is handled through the orchestrator’s jira_plugin, while Azure DevOps integration is modeled through an MCP-oriented path plus the dedicated src/backend/mcp_server. The MCP server exposes Azure DevOps and Jira service adapters, including synthetic/static data for demo or offline scenarios. This makes tool access a separate service boundary rather than embedding every API client in the orchestrator.

8. Shared contracts and cross-cutting code

src/backend/common is a shared package used by the services. It contains request/response schemas, configuration models, HTTP/caching clients, telemetry/logging, safety checks, and generic helpers. Architecturally, this is the glue layer that keeps the services consistent without coupling them tightly.

9. Safety, telemetry, and storage

The common package includes text/image safety utilities and OpenTelemetry-style logging/tracing support. The README also calls out Azure Content Safety, Azure Storage, and Key Vault: storage is used for durable artifacts such as visualization outputs, Key Vault for secrets, and telemetry for observability across services.

10. Azure deployment topology

The infra directory is the deployment boundary. Core modules provision networking, container apps environment, container registry, monitoring, storage, Key Vault, and AI project resources. App modules then deploy the frontend, session manager, orchestrator, Redis, and MCP server into that foundation.

11. Runtime and packaging

Each backend service has its own Dockerfile and requirements file, so the runtime unit is a container per service. The repo also includes docker-compose.yml, devcontainer support, and deployment scripts for local and cloud workflows, which indicates the architecture is designed to run both locally and in Azure-managed containers.

12. Delivery pipeline

.github/workflows and .azdo/pipelines show that CI/CD is supported in both GitHub and Azure DevOps. The scripts under scripts/ handle image build/push and deployment orchestration, which reinforces that deployment is infrastructure-driven rather than manually assembled.

13. Primary end-to-end flow

A user sends a chat message from the React app → the session manager receives it over WebSocket → the orchestrator plans the request and invokes the right agent → the agent calls Jira, Azure DevOps/MCP, or visualization tooling as needed → the orchestrator composes the final answer → the session manager returns it to the browser. This is the key diagram path to preserve.

14. Important architectural boundaries

The main boundaries are: UI vs real-time session gateway, session gateway vs AI orchestration, orchestration vs external tools, and app runtime vs Azure infrastructure. Those separations are the core of the repository’s design and are the most important lines to draw in an architecture diagram.