yas-gitops

GitOps entry point for YAS deployments. ArgoCD uses the App of Apps pattern: root-app-dev.yaml and root-app-staging.yaml render this Helm chart, and the chart renders one child Application per service from the environment values.

Current structure

.
├── Chart.yaml
├── README.md
├── root-app-dev.yaml
├── root-app-staging.yaml
├── templates
│   ├── _helpers.tpl
│   └── applications.yaml
├── values.yaml
├── values-dev.yaml
└── values-staging.yaml

Environments

Environment	Values file	Destination namespace	Image tag format
dev	values-dev.yaml	dev	<service_name>_<short_commit_id>
staging	values-staging.yaml	staging	<service_name>_v1.Y.Z

Examples:

inventory_a91cd22
customer_v1.1.1
backoffice-bff_v1.2.0

Staging versioning

Jenkins owns version calculation and writes the final image tag back to values-staging.yaml.

Rules:

• X is always 1 in v1.Y.Z.
• feat/* increments Y and resets Z to 0.
• fix/* increments Z.
• Jenkins reads the latest Git tag, calculates the next version, creates and pushes the tag, and retries if a concurrent build already created it.

Application rendering

Each service is declared under applications: in the selected values file. Important fields:

• name: ArgoCD child Application base name.
• path: Helm chart path in the application source repo.
• syncWave: ArgoCD ordering.
• image.repositoryName: image repository name under global.image.registry.
• image.repositoryParameter: Helm value key used by the child chart.
• image.tag: exact tag promoted by Jenkins.
• helm.parameters: service-specific Helm parameter overrides.

All child Applications include:

• automated sync
• selfHeal
• prune
• CreateNamespace=true
• foreground prune propagation
• Kubernetes recommended labels
• ArgoCD/GitOps traceability annotations

The default Helm parameters set common strategy values to Recreate so child charts can enforce one active version per namespace. Confirm each child chart's Deployment consumes one of strategy.type, deployment.strategy.type, or backend.strategy.type.

Root Applications

Apply one root Application per environment:

kubectl apply -f root-app-dev.yaml
kubectl apply -f root-app-staging.yaml

ArgoCD detects this repository as a Helm chart because the root path contains Chart.yaml and each root Application sets source.helm.valueFiles.

Suggested production layout

For larger teams, split environment concerns into a top-level environments directory while preserving App of Apps:

.
├── charts
│   └── app-of-apps
│       ├── Chart.yaml
│       ├── templates
│       │   ├── _helpers.tpl
│       │   └── applications.yaml
│       └── values.yaml
├── environments
│   ├── dev
│   │   ├── root-app.yaml
│   │   └── values.yaml
│   └── staging
│       ├── root-app.yaml
│       └── values.yaml
└── docs
    └── release-versioning.md

This keeps root Applications, environment values, and reusable chart logic cleanly separated while keeping ArgoCD's root app model unchanged.