37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
# ArgoCD (GitOps deployment)
|
|
|
|
Deployment uses the **team's existing ArgoCD instance** (not self-hosted by
|
|
this project) rather than a custom push-based CD pipeline. See
|
|
`docs/adr/0002-argocd-gitops.md` for the rationale.
|
|
|
|
## Flow
|
|
|
|
1. CI (`infra/ci/github-actions/*-ci.yml`) builds and pushes a container image
|
|
per app on merge to master, then bumps that app's image tag in
|
|
`infra/helm/medical-chatbot/values-<env>.yaml` (or a per-app values file)
|
|
and pushes that commit back to the repo. CI never runs `kubectl apply` or
|
|
`helm upgrade` directly.
|
|
2. ArgoCD (team-managed, pointed at this repo) watches `infra/argocd/applications/<env>/`
|
|
and `infra/helm/medical-chatbot/`, detects the values-file change, and
|
|
syncs the cluster to match — this is the actual deploy step, owned by
|
|
ArgoCD, not by our CI.
|
|
3. Promotion between environments (dev -> staging -> prod) is a Git operation
|
|
(merge/PR that changes the target values file or image tag for that env),
|
|
not a manual `kubectl`/`helm` command.
|
|
|
|
## Files
|
|
|
|
- `applications/dev/app.yaml`, `applications/staging/app.yaml`,
|
|
`applications/prod/app.yaml` — one ArgoCD `Application` CR per environment,
|
|
each pointing at this repo + the `infra/helm/medical-chatbot` chart with
|
|
that environment's values file.
|
|
|
|
## TODO once the team's ArgoCD instance details are known
|
|
|
|
- Fill in `spec.destination.server` (target cluster API server / context name)
|
|
in each `app.yaml` — currently a placeholder.
|
|
- Confirm which ArgoCD `project` (RBAC scoping) these Applications should
|
|
belong to, instead of the placeholder `default`.
|
|
- Confirm the repo URL placeholder in each `app.yaml` once the GitHub repo
|
|
exists (filled in as part of the initial scaffold commit/push).
|