Cheat notes · Module 07 · Real-world delivery

Three repositories and multiple sources

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Code, environment settings and platform config change at different speeds with different risks, so they live in three repos. One Application reads the chart from one repo and the values from another with sources and a ref. A tag is a release; a change to the environment repo is a deploy.

Remember

Application repo (checkout-app): code, CI and the chart. A release is a Git tag. Merging here deploys nothing.
Environment repo (checkout-config): values per environment. Changing a tag or a value here is a deploy.
Platform repo (argocd-platform): Argo CD, Applications, projects. Few changes, widest blast radius.
Multiple sources: sources: is a list. A source with ref: config only contributes files; another source reads one as $config/helm/prod.yaml.
One revision per source: argocd app history shows only the first source. argocd app get APP --show-operation lists every source's commit under Sync Revision:, in source order.
Immutable fields: a Deployment's spec.selector cannot change. Switching from Kustomize to the chart needed a delete and recreate; in prod, plan renames (new name, then delete the old).
Not a grouping tool: one Application per thing, grouped by an app of apps. Bundling unrelated things into sources loses separate sync, health and history.

Pitfalls

Moving a release tag deploys to every environment that pins it, with no change to the environment repo. Protect release tags on GitHub (tag rulesets).
Reading history and concluding nothing changed: it only shows the first source.
field is immutable on spec.selector comes from Kubernetes, not Argo CD.

Commands

`git tag v1.0.0 && git push origin v1.0.0`	Release the chart
`helm lint chart`	Check the chart
`helm template checkout CHART_DIR -f helm/prod.yaml`	Render with one environment's values
`argocd app get APP --show-operation \| grep 'Sync Revision'`	The deployed commit of every source
`argocd app get APP --hard-refresh`	Re-read Git and drop cached manifests (a tag moved)

Chart from one repo, values from another

sources:
  - repoURL: https://github.com/YOUR_GITHUB_USER/checkout-app.git           # source 1: the chart
    path: chart
    targetRevision: v1.0.0      # a release
    helm:
      valueFiles:
        - $config/helm/prod.yaml  # read from the ref source
  - repoURL: https://github.com/YOUR_GITHUB_USER/checkout-config.git         # source 2: the values
    targetRevision: main
    ref: config                 # the nickname behind $config

Test yourself

Answer in your head first, then open the answer.

Which change is a deploy to prod?

A change to helm/prod.yaml in checkout-config.

What does ref: config do?

Names a source so other sources can read files from it as $config/.... It deploys nothing itself.

One Application for checkout, catalog and Traefik: good idea?

No. Unrelated things lose separate sync, health and history. One Application each, grouped by an app of apps.

Why does history keep saying v1.0.0 after a values change?

It shows only the first source, the chart, which did not change.

Where module 07 leaves you: Three repos exist: argocd-platform (Applications), checkout-app (the chart, tagged v1.0.0) and checkout-config (values per environment). checkout-dev and checkout-prod deploy from chart plus values, and prod now runs 6.7.1.