validate/platform-docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: README for component/default/sonar-test-nest4 #16

Closed
demo-bot wants to merge 1 commits from documentor-agent-component-default-sonar-test-nest4-doc-65d225410e9d into main
pull from: documentor-agent-component-default-sonar-test-nest4-doc-65d225410e9d
merge into: validate:main
Conversation 0 Commits 1 Files Changed 1 +31 -24
1 changed files with 31 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
catalog/component/default/sonar-test-nest4/README.md
View File

@@ -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