@@ -293,75 +293,6 @@ AICR ships five output adapters in
293293` HelmRelease` s). **Components do not need to be deployer-aware** —
294294the bundler renders per-deployer from one component definition.
295295
296- # ## Deployment ordering
297-
298- **One model, three projections.** Every deployer derives ordering from
299- the same source : each component's declared `dependencyRefs`. What
300- differs is how faithfully a deployer's native mechanism can express
301- that dependency graph. For the concurrent deployers, components with no
302- path between them are independent and roll out **concurrently**, while a
303- real dependency **gates** (the dependent waits for its dependency to be
304- healthy). The `NNN-<name>/` folder numbers reflect `DeploymentOrder`
305- (a topological serialization) for readability, and drive the two
306- deliberately linear paths — the helm `deploy.sh` and `--serial` mode —
307- which install strictly in that order regardless of tiers.
308-
309- ` pkg/recipe` exposes the graph two ways, and deployers pick whichever
310- fits their mechanism :
311-
312- - ` TopologicalSort` → a flat `DeploymentOrder` (one valid serialization).
313- - ` ComponentRefsTopologicalLevels` → dependency-depth **tiers**, where a
314- tier holds exactly the components whose dependencies are all satisfied
315- by earlier tiers (so a tier's members are mutually independent).
316-
317- **flux — the exact DAG.** Flux's `dependsOn` is a native dependency
318- graph, so the flux deployer projects each component's declared
319- `dependencyRefs` directly onto it : a `HelmRelease`'s `dependsOn` names
320- exactly its dependencies' terminal releases, nothing more. This is the
321- most faithful and most parallel rendering — a component waits only for
322- what it actually needs — and it reads naturally to flux users because
323- ` dependsOn` mirrors `dependencyRefs` one-for-one. See `declaredDependsOn`.
324-
325- **argocd / argocd-helm — tiers as sync-wave bands.** Argo CD's
326- ` sync-wave` is a single integer per Application. Applications sharing a
327- wave sync together, and Argo advances to a higher wave only once the
328- current one is healthy — ordered *bands*, a partial order rather than a
329- total one. Because a component gets one integer, it cannot express "wait
330- for A but not B" when A and B sit at the same depth, so the DAG is
331- **approximated** by tiers: `wave = tier*4 + phase`, where the
332- per-component phase orders `-pre` → primary → `-post` → `-readiness`.
333- The stride-4 band width keeps consecutive tiers disjoint, so a tier's
334- readiness gate still blocks the next tier. The cost of the coarser
335- banding is mild over-constraint (a component waits for its whole prior
336- tier, not just its own dependencies). See `waveForFolder`.
337-
338- **helmfile — tiers as sequential sub-helmfiles.** Emits one
339- ` level-N.yaml` sub-helmfile per tier, processed in sequence so each
340- tier's CRDs land in the cluster's REST mapper before the next tier's
341- plan is rendered (issue # 914). Within a sub-helmfile, `needs:` edges
342- chain only a component's own `-pre` → primary → `-post` releases;
343- independent components in the tier carry no edge, so helmfile applies
344- them concurrently. Cross-tier ordering is the sub-helmfile sequence, not
345- per-release `needs:` — the same tier approximation as argocd. See
346- ` buildHelmfile` .
347-
348- **helm — deliberately serial.** The `deploy.sh` installs one component
349- at a time in `DeploymentOrder`, trading parallelism for the simplest
350- possible shell. The readiness gates already sequence it correctly.
351-
352- # ### Disabling parallelism (`--serial`)
353-
354- ` aicr bundle --serial` forces every deployer to install components
355- strictly one at a time in `DeploymentOrder`, an escape hatch for
356- reproducing the pre-parallelism ordering or bisecting a misbehaving
357- rollout. It affects the four concurrent deployers : argocd and
358- argocd-helm fall back to a linear sync-wave per folder, flux chains each
359- ` HelmRelease` ` dependsOn` to the previous component instead of
360- projecting the DAG, and helmfile chains every release to its predecessor
361- via `needs:` (one linear apply chain) instead of only within a
362- component. The helm `deploy.sh` is already serial, so the flag is a
363- no-op for it. Off by default.
364-
365296See [index.md](index.md#community-standard-deployment-targets) for
366297the deployer matrix.
367298
0 commit comments