diff --git a/catalog/component/default/sonar-test-nest4/README.md b/catalog/component/default/sonar-test-nest4/README.md index ef66678..59f8097 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-15T15:19:14+00:00" +generated_at: "2026-05-15T15:19:48+00:00" human_edited: false source_entity: "Component/default/sonar-test-nest4" source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4" @@ -9,61 +9,68 @@ 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 RESTful API for managing items, including endpoints for CRUD operations. It is designed to be lightweight, scalable, and observable, with integrated OpenTelemetry instrumentation 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 RESTful API for managing items, including endpoints for creating, retrieving, updating, and deleting items. It is designed with observability in mind, exposing health and metrics endpoints for monitoring. -This service plays a key role in the demo-apps domain, serving as a foundational component for item management. It is deployed on Azure Kubernetes Service (AKS) via Humanitec, with container images stored in Azure Container Registry (ACR). The CI/CD pipeline is managed through Gitea Actions, ensuring automated builds, tests, and deployments across environments (`dev`, `staging`, `prod`). +This service plays a critical role in the demo-apps domain, adhering to a structured branch and promotion model (`dev → staging → prod → main`) to ensure quality and reliability across environments. It is deployed to Azure Kubernetes Service (AKS) via Humanitec, leveraging Score for deployment orchestration. ## Repository | Field | Value | |----------------|-----------------------------------------------------------------------------------------------------------------| -| Source Repo | [validate/sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4) | -| Branch | `dev` → `staging` → `prod` (→ `main` SoR) | +| Source Repo | [sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4) | +| Branch | `dev` | | ArgoCD App | — | | Namespace | `dev` | ## Architecture -`sonar-test-nest4` follows a stateless architecture, leveraging the `typescript-nestjs` framework. Key components include: +`sonar-test-nest4` follows a modern microservice architecture: - **Runtime**: `typescript-nestjs` - **Container Port**: `3000` -- **Health Check**: `/health` -- **Metrics Endpoint**: `/metrics` (Prometheus format) -- **Image Registry**: Azure Container Registry (`bstagecjotdevacr`) +- **Endpoints**: + - `/api/items` for CRUD operations on items. + - `/health` for health checks. + - `/metrics` for Prometheus-compatible metrics. +- **Deployment Flow**: + - CI/CD pipelines in Gitea Actions handle build, test, and deployment. + - Images are pushed to Azure Container Registry (ACR). + - Humanitec API orchestrates deployments to AKS using Score. -The deployment flow is managed through Gitea Actions CI/CD workflows: -1. **build-push.yml**: Builds and tests the application, then pushes the container image to ACR. -2. **deploy-humanitec.yml**: Deploys the service to AKS using Humanitec's API and Score configuration. - -Promotions between environments (`dev`, `staging`, `prod`) are triggered via PRs, with CI gates and approval requirements ensuring quality control. +The service is stateless and integrates seamlessly with the platform's observability stack, including OpenTelemetry instrumentation. ## Configuration | Config Key | Value | |------------------|--------------------| -| `runtime` | `typescript-nestjs` | +| `runtime` | `typescript-nestjs`| | `health_path` | `/health` | | `container_port` | `3000` | +Additional configuration details are managed via `.platform/config.yaml` in the repository. + ## Operations ### Deployment Steps -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 before merging. -3. Use the Backstage CI/CD tab to trigger promotions between environments. + +1. Push changes to the `dev` branch for automatic deployment to the dev 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. ### Runbook Notes -- Monitor `/health` for service health status. -- Use `/metrics` for Prometheus-based observability. -- Refer to `.platform/config.yaml` for runtime-specific configurations. + +- **Health Check**: Verify service health via `/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. +- **Prometheus Metrics**: Exposed at `/metrics`. +- **Health Endpoint**: `/health`. ## Dependencies