diff --git a/catalog/component/default/sonar-test-nest4/README.md b/catalog/component/default/sonar-test-nest4/README.md index 6df1702..95193c3 100644 --- a/catalog/component/default/sonar-test-nest4/README.md +++ b/catalog/component/default/sonar-test-nest4/README.md @@ -1,7 +1,7 @@ --- title: "sonar-test-nest4" generated_by: documentor-agent -generated_at: "2026-05-18T10:03:38+00:00" +generated_at: "2026-05-21T07:55:31+00:00" human_edited: false source_entity: "Component/default/sonar-test-nest4" source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4" @@ -9,9 +9,9 @@ source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4" ## Overview -`sonar-test-nest4` is a stateless microservice built using the `typescript-nestjs` runtime. It was scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. The service provides a REST API for managing items, including CRUD operations, and exposes observability endpoints for health checks and Prometheus metrics. +`sonar-test-nest4` is a stateless microservice built using the `typescript-nestjs` runtime. It was scaffolded from the **Create Microservice** golden-path template on the Kyndryl Platform. The service provides a REST API for managing items, including CRUD operations, and is instrumented with OpenTelemetry for observability. It is designed to integrate seamlessly into the platform's CI/CD pipeline, leveraging Humanitec for deployment orchestration and Azure Container Registry for image storage. -This service plays a key role in the broader system by offering a scalable and observable backend for item management. It is deployed using Humanitec's API-driven deployment model, leveraging Azure Kubernetes Service (AKS) and Azure Container Registry (ACR). The CI/CD pipeline automates builds, tests, and deployments across development, staging, and production environments. +The service plays a critical role in the demo-apps domain, showcasing best practices for microservice development, deployment, and observability. It is managed by the platform engineering team and adheres to a strict branch promotion model to ensure quality and stability across environments. ## Repository @@ -24,52 +24,54 @@ This service plays a key role in the broader system by offering a scalable and o ## Architecture -`sonar-test-nest4` follows a modern microservice architecture with the following components: +`sonar-test-nest4` follows a modern microservice architecture: - **Runtime**: `typescript-nestjs` - **Container Port**: `3000` - **Endpoints**: - - `/api/items` for CRUD operations - - `/health` for health checks - - `/metrics` for Prometheus metrics + - `/api/items` for CRUD operations on items. + - `/health` for health checks. + - `/metrics` for Prometheus-compatible metrics. - **Deployment Flow**: - - Push to `dev`, `staging`, or `prod` triggers CI/CD workflows: - - `build-push.yml`: Builds and tests the service, then pushes the container image to Azure Container Registry. - - `deploy-humanitec.yml`: Deploys the service to AKS using Humanitec's Score-based deployment model. -- **Branch Model**: - - `dev`: Active development, auto-deploys to the dev environment. - - `staging`: Pre-production, promoted from `dev` via PR. - - `prod`: Production, promoted from `staging` via PR. - - `main`: System of record, receives merges from `prod`. + - CI/CD pipelines in Gitea Actions handle build, test, and deployment. + - Images are pushed to Azure Container Registry (`bstagecjotdevacr`). + - Humanitec orchestrates deployments to AKS using Score files. + +The service is designed for scalability and observability, with OpenTelemetry instrumentation and Prometheus metrics exposed at `/metrics`. ## Configuration -| Config Key | Value | -|------------------|-------------------| +| Config Key | Value | +|------------------|------------------| | `runtime` | `typescript-nestjs` | -| `health_path` | `/health` | -| `container_port` | `3000` | +| `health_path` | `/health` | +| `container_port` | `3000` | + +Additional configuration details are managed via `.platform/config.yaml` and Humanitec Score files. ## Operations ### Deployment Steps -1. Push changes to the `dev` branch for automatic deployment to the dev environment. -2. Open a PR to promote changes from `dev` to `staging`. Ensure CI tests pass and obtain one approval. -3. Open a PR to promote changes from `staging` to `prod`. Ensure CI tests pass and obtain one approval. -4. Merge changes from `prod` to `main` for system-of-record updates. +1. Push changes to the `dev` branch for automatic deployment to the development environment. +2. Open a PR for promotion to `staging` or `prod`. Ensure CI tests pass and obtain one approval. +3. Merge PR to trigger deployment to the target environment. -### Observability Endpoints +### Runbook Notes -- `/health`: Returns `{"status":"UP"}` for health checks. -- `/metrics`: Exposes Prometheus metrics for monitoring. +- **Health Check**: Verify service health at `/health`. +- **Metrics**: Monitor Prometheus metrics at `/metrics`. +- **Promotion Flow**: + - `dev → staging`: Requires CI gate and approval. + - `staging → prod`: Requires CI gate and approval. + - `prod → main`: Merge via PR after release. ## Observability -- **Grafana Dashboard**: [Opentelemetry Application Observability](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4) -- **Prometheus Metrics**: Enabled (`/metrics` endpoint). -- **Chaos Mesh**: Enabled for resilience testing. -- **K6 Load Testing**: Configured via `k6-test-sonar-test-nest4` in the `dev` namespace. +- **Grafana Dashboard**: [OpenTelemetry Application Observability](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=sonar-test-nest4) +- **Prometheus Metrics**: Exposed at `/metrics`. + +_Chaos Mesh and K6 load testing are enabled for this service._ ## Dependencies