10 Commits

Author SHA1 Message Date
1af6f3114d docs: generate README for domain/default/platform [documentor-agent] 2026-05-28 11:47:39 +00:00
0527720ef5 Merge pull request 'docs: documentation for validate/petclinic-demo-andrej4' (#24) from documentor-validate-petclinic-demo-andrej4-f899299f into main 2026-05-28 09:07:34 +00:00
823a05daf7 docs: update _meta.json for component/default/petclinic-demo-andrej4 [documentor-agent] 2026-05-28 09:07:29 +00:00
16e8a8cd36 docs: generate README for component/default/petclinic-demo-andrej4 [documentor-agent] 2026-05-28 09:07:28 +00:00
4aa5c46eee Merge pull request 'docs: documentation for validate/petclinic-demo-andrej4' (#23) from documentor-validate-petclinic-demo-andrej4-52fb7e3b into main 2026-05-28 08:58:19 +00:00
bab34ff3f8 docs: update _meta.json for component/default/petclinic-demo-andrej4 [documentor-agent] 2026-05-28 08:58:14 +00:00
73a01ffebb docs: generate README for component/default/petclinic-demo-andrej4 [documentor-agent] 2026-05-28 08:58:13 +00:00
3577ca78cf Merge pull request 'docs: documentation for validate/sonar-test-nest4' (#22) from documentor-validate-sonar-test-nest4-01e0755e into main 2026-05-21 08:46:14 +00:00
c05892070f docs: update _meta.json for component/default/sonar-test-nest4 [documentor-agent] 2026-05-21 08:46:10 +00:00
ea04340ef8 docs: generate README for component/default/sonar-test-nest4 [documentor-agent] 2026-05-21 08:46:08 +00:00
5 changed files with 146 additions and 60 deletions

View File

@@ -0,0 +1,90 @@
---
title: "Petclinic Demo Application"
generated_by: documentor-agent
generated_at: "2026-05-28T09:07:15+00:00"
human_edited: false
source_entity: "Component/default/petclinic-demo-andrej4"
source_repo: "https://gitea.kyndemo.live/validate/petclinic-demo-andrej4"
---
## Overview
The **Petclinic Demo Application** is a deployment of the Spring PetClinic sample application, tailored for demonstration purposes. It showcases a modern Java-based microservice architecture, leveraging Spring Boot for rapid development and deployment. The application is deployed via ArgoCD into the `demo-apps` namespace and includes integrations for observability, load testing, and chaos engineering.
This service plays a critical role in demonstrating best practices for application lifecycle management, including CI/CD workflows, OpenTelemetry instrumentation, and Kubernetes-based deployments. It serves as a reference implementation for teams adopting similar technologies and workflows.
## Repository
| Property | Value |
|----------------|---------------------------------------------------------------------------------------------------------|
| **Source Repo**| [Petclinic Demo Repository](https://gitea.kyndemo.live/validate/petclinic-demo-andrej4) |
| **Branch** | `main` |
| **ArgoCD App** | [petclinic-demo-andrej4](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4) |
| **Namespace** | `demo-apps` |
## Architecture
The Petclinic Demo Application is built on the Spring Boot framework and deployed as a containerized service in Kubernetes. Key architectural components include:
- **Spring Boot Application**: The core service, providing RESTful APIs and a web interface.
- **Database**: Configurable to use H2 (in-memory), MySQL, or PostgreSQL, depending on the active profile.
- **OpenTelemetry Integration**: Auto-instrumentation for tracing, metrics, and logs, exported to an OTel Collector.
- **ArgoCD**: Continuous deployment and synchronization from the `main` branch.
- **K6 Load Testing**: Configured for performance testing.
- **Chaos Mesh**: Enabled for chaos engineering experiments.
Data flows through the application from user interactions to backend services, with observability tools providing insights into performance and reliability.
## Configuration
| Configuration Item | Description |
|--------------------------|----------------------------------------------------------------------------------------------|
| `spring.profiles.active` | Sets the active profile (`default`, `mysql`, `postgres`). |
| `OTel Collector URL` | `http://otel-collector.monitoring.svc.cluster.local:4318` |
| `Database URL` | Configurable for H2, MySQL, or PostgreSQL. |
| `K6 ConfigMap` | `k6-test-petclinic-demo-andrej4` |
## Operations
### Deployment
1. Clone the repository:
```bash
git clone https://gitea.kyndemo.live/validate/petclinic-demo-andrej4.git
cd petclinic-demo-andrej4
```
2. Push changes to the `main` branch:
```bash
git add . && git commit -m "your change" && git push origin main
```
3. ArgoCD will automatically sync changes to the `demo-apps` namespace.
### Rollback
1. Open the [ArgoCD UI](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4).
2. Click **History and Rollback**.
3. Select the desired revision and click **Rollback**.
Alternatively, revert the commit in Git and push — ArgoCD will auto-sync the rollback.
## Observability
This service is fully instrumented with OpenTelemetry. Observability data is visualized in Grafana.
- **Grafana Dashboard**: [View Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=petclinic-demo-andrej4)
- **Alerting**: Configured via Grafana with label selector `app.kubernetes.io/instance=petclinic-demo-andrej4`.
_Not configured — see platform observability docs for additional details._
## Dependencies
- `component:default/argocd-service`
- `resource:default/k6-operator`
- `resource:default/otel-collector`
## Links
- [Live Application](https://petclinic-demo-andrej4.kyndemo.live)
- [Repository](https://gitea.kyndemo.live/validate/petclinic-demo-andrej4)
- [ArgoCD App](https://argocd.kyndemo.live/applications/petclinic-demo-andrej4)
- [Grafana Dashboard](https://grafana.kyndemo.live/d/otel-app-observability-v2/opentelemetry-application-observability?orgId=1&var-app=petclinic-demo-andrej4)

View File

@@ -0,0 +1,12 @@
{
"sourceShas": {
"catalog-info.yaml": "7f8e08e4d71a45033f49d9190e35fd08ebbb7645",
"README.md": "ef9b745ac26efecf8340b75eea18b8151ba7a86e",
"docs/adr/index.md": "b9a0b93743cf579be35101bbc63b29356be2849f",
"docs/index.md": "f7bef9b17f650992e3a89fbecf37eb0ea948b8e0",
"docs/runbooks/index.md": "f9796c4d1a113b786df89cd74dee0f50d98d6025"
},
"promptVersion": "1.0",
"generatedAt": "2026-05-28T09:07:25+00:00",
"contentHash": "625799bc84a8ff7004d26604e1d76286e95b9a3617abf6c014146a04202ff719"
}

View File

@@ -1,7 +1,7 @@
---
title: "sonar-test-nest4"
generated_by: documentor-agent
generated_at: "2026-05-21T07:55:31+00:00"
generated_at: "2026-05-21T08:45:51+00:00"
human_edited: false
source_entity: "Component/default/sonar-test-nest4"
source_repo: "https://gitea.kyndemo.live/validate/sonar-test-nest4"
@@ -9,69 +9,64 @@ 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 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.
`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 endpoints for CRUD operations. It is designed to be lightweight, scalable, and observable, with integrated OpenTelemetry instrumentation and Prometheus metrics.
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.
This service plays a critical role in the demo-apps domain, serving as a testbed for platform capabilities such as CI/CD pipelines, observability, and load testing. It is managed via Humanitec and deployed to Azure Kubernetes Service (AKS) using Score-based configurations.
## Repository
| Field | Value |
|----------------|------------------------------------------------------------------------------------------------------------------------------------|
| Source Repo | [validate/sonar-test-nest4](https://gitea.kyndemo.live/validate/sonar-test-nest4) |
| 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 modern microservice architecture:
`sonar-test-nest4` follows a modern microservice architecture with the following components:
- **Runtime**: `typescript-nestjs`
- **Container Port**: `3000`
- **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 (`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`.
- `/api/items` for CRUD operations
- `/health` for health checks
- `/metrics` for Prometheus metrics
- **Deployment**:
- Images are built and pushed to Azure Container Registry (ACR).
- Humanitec API triggers deployments to AKS using Score-based configurations.
- **CI/CD**:
- Gitea Actions workflows (`build-push.yml` and `deploy-humanitec.yml`) automate build, test, and deployment processes.
- Promotion between environments (`dev → staging → prod`) is gated by CI checks and manual approvals.
## 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.
Additional configuration options are managed via `.platform/config.yaml` and Humanitec score files.
## Operations
### Deployment Steps
### Deployment Flow
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.
1. Push changes to the `dev` branch to trigger automatic builds and deployments to the dev environment.
2. Promote changes to `staging` or `prod` via PRs, requiring CI checks and one approval.
3. Use Backstage's CI/CD tab to monitor and trigger promotions between environments.
### Runbook Notes
- **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.
- **Health Check**: Verify service health via `/health`.
- **Metrics**: Access Prometheus metrics at `/metrics`.
- **Load Testing**: K6 is enabled for load testing, with configurations stored in the `k6-test-sonar-test-nest4` ConfigMap.
## 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**: Exposed at `/metrics`.
_Chaos Mesh and K6 load testing are enabled for this service._
- **Prometheus Metrics**: Exposed at `/metrics` on port `3000`.
## Dependencies

View File

@@ -1,6 +1,6 @@
{
"sourceShas": {
"catalog-info.yaml": "1dfa78366377f0f0c1d72669a551f44e90e8f6b1",
"catalog-info.yaml": "aa72b708c50b03b5dd454112e1f50ab88546e586",
".platform/initialized.md": "24a574f77ac17059b313a824398b9bb19263232e",
"README.md": "393357c07b620a60ef22f449987d9195d533dd10",
"docs/api.md": "86776bdd5e2fbe634709920102282ed589927c5b",
@@ -8,6 +8,6 @@
"docs/index.md": "81f0ec2243665ad41daf93202c872cfc023eb21a"
},
"promptVersion": "1.0",
"generatedAt": "2026-05-21T07:55:50+00:00",
"contentHash": "86c1649daaec999ba977c2baee3ad51bd3f679de80480fb0c830c0ef3626ece1"
"generatedAt": "2026-05-21T08:46:06+00:00",
"contentHash": "a82efb2e2e92a9bcb63354c3faab85a4f8438528764c04da61699539d261fa17"
}

View File

@@ -1,44 +1,33 @@
```markdown
---
title: "Platform"
generated_by: documentor-agent
generated_at: "2026-05-05T10:06:41+00:00"
generated_at: "2026-05-28T11:47:34+00:00"
human_edited: false
source_entity: "Domain/default/platform"
---
# Platform
> Platform domain for platform engineering capabilities and tooling.
## Overview
The Platform domain serves as the central hub for platform engineering capabilities and tooling within the organization. It encompasses systems and tools that enable efficient development, deployment, and management of software across the organization. This domain is designed to provide foundational services and frameworks that support the broader engineering ecosystem.
The Platform domain encompasses platform engineering capabilities and tooling. It serves as the foundation for enabling efficient development, deployment, and operation of software systems across the organization. This domain focuses on providing shared services, frameworks, and tools that streamline workflows and enhance developer productivity.
The systems within this domain are critical for ensuring scalability, reliability, and developer productivity. By consolidating platform-related resources and expertise, the Platform domain helps streamline operations and fosters innovation.
By centralizing platform engineering efforts, the Platform domain ensures consistency, scalability, and reliability across various systems. It supports the organization's technical infrastructure and empowers teams to deliver high-quality solutions faster.
## Ownership
| Field | Value |
|---|---|
| Owner | group:default/platform-engineering |
| Namespace | default |
| Labels | — |
| Owner | Namespace | Labels |
|--------------------------------|-----------|--------|
| group:default/platform-engineering | default | — |
## Systems
- `system:default/agentic-agents`
- `system:default/cjot-backstage`
- `system:default/platform-engineering`
## Relationships
The Platform domain includes the following systems:
- **Agentic Agents** (`system:default/agentic-agents`)
- **CJOT Backstage** (`system:default/cjot-backstage`)
- **Petclinic Demo Jonathan Scaf 2** (`system:default/petclinic-demo-jonathan-scaf-2`)
- **Platform Engineering** (`system:default/platform-engineering`)
<!-- TODO: FILL IN -->
## Links
_No links configured._
## Notes
Platform domain for platform engineering capabilities and tooling.
```
_No links configured._