Project structure
DevOps white-label project consists of multiple repositories, each with a clearly defined responsibility. This project is tailored to meet specific customer needs and requirements. It leverages platform components (packages) and references other artifacts, including repositories, Helm charts, pipeline templates, and more. Customer-specific projects are initially created as clones of the white-label project.
White-label project structure
Services
Repositories that host the code for various services. The structure of a service repository is described in detail in the documentation.
naming convention: svc-service-name
Packages (.NET)
Repositories that host the code for reusable .NET packages. The structure of a package repository is explained further in the documentation.
- services reference packages via a NuGet feed
- NuGet feeds can reference another feed (upstream), typically the platform feed
naming convention: dotnet-package-name
Deployment
repo deployment-templates
- contains templates for deployments
- typically includes configuration files used as input for further processing (e.g.,
helm template)
- typically includes configuration files used as input for further processing (e.g.,
- each environment is organized into a dedicated folder
- git-ops approach
repo deployment-config
- contains deployment manifests (which may be rendered)
- acts as the source of truth for deployments, with tools like Flux or ArgoCD responsible for applying manifests to the cluster
- each environment is represented by a dedicated folder
- git-ops approach
Contract (OAS)
repo api-contracts-be
- contains BE service contracts for further processing
- supports operations such as splitting and merging contracts
- results are copied to other repositories with specific responsibilities
- BE contracts are automatically propagated to this repository from service repositories
repo api-contracts
- contains BE service contracts with endpoints for client applications (public endpoints only)
- includes scripts for generating client http packages (e.g.
dart,ts, etc.)
repo deployment-templates
- contains configuration files for further customization of API gateway
- definition how to expose and secure endpoints
Helm templating
Helm is used for templating deployment manifests, enabling a more efficient and flexible deployment process.
repo helm-charts
- hosts Helm chart definitions for various components (e.g., services, websites)
repo helm-registry
- contains packaged Helm charts (
.tgzfiles) - functions as a simplified Helm chart registry
- these packages are used for templating during the deployment process
Pipeline templates
- contains scripts and pipeline definitions, including jobs, steps, and complete pipelines
- designed to be referenced and utilized by other software components (e.g., services, packages)
- simplifies and standardizes common automation tasks
Platform structure and introduction
This section provides guidance on leveraging Azure DevOps for managing core platform components and launching new projects efficiently. It highlights the available repositories, tools, and templates that simplify project creation, integration, and deployment.
Service as a deployable unit
A service represents a standalone, deployable component within the project. Each service is designed to operate independently, encapsulating specific functionality, and is packaged for deployment in a k8s environment. This approach ensures modularity, scalability, and ease of maintenance.