Vue d'ensemble du flow release Spektrum

Le flow release standard repose sur deux pipelines GitLab distincts qui se relayent, déclenchés par deux événements consécutifs.

Le flow

[ Dev local : npx @spektrum/release-util release --env staging|prod ]
   │   crée branche release/X.Y.Z[-staging.N] + MR vers trunk
   │   la MR porte un commit "chore(release): X.Y.Z[-staging.N]"
   ▼
[ MR mergée sur trunk (fast-forward ou merge commit, JAMAIS squash) ]
   │
   │   PIPELINE TRUNK
   │
   ├── release-tag       → push du tag annoté X.Y.Z[-staging.N]
   ├── release-badges    → SVGs prod/staging artefact non-expirant
   └── publish-docker-*  → (option) build + push image OCI
                           (intègre release-tag + release-badges)
   │
   ▼
[ Push de tag X.Y.Z ou X.Y.Z-staging.N ]
   │
   │   PIPELINE DE TAG
   │
   ├── release-detect    → dotenv VERSION / CHANNEL / RELEASE_TYPE
   └── jobs aval         → consomment release-detect via needs+artifacts
                           (OTA upload, Fastlane, déploiement K8s, etc.)

Modèle mental

• Pipeline trunk : déclenché par le merge de la MR de release. Tout ce qui doit être fait synchrone avec l'apparition d'une nouvelle version (tag, badges, build d'artefacts) vit ici.
• Pipeline de tag : déclenché par le tag poussé à l'étape précédente. Tout ce qui a besoin de connaître la version "officielle" et d'être déclenché par version (upload OTA, déploiement, build mobile) vit ici.

La séparation existe parce que les rules: GitLab ne peuvent pas évaluer des variables produites par un job aval — donc les consommateurs de VERSION/CHANNEL/RELEASE_TYPE doivent tourner dans un pipeline qui sait déjà qu'on est sur une version (via $CI_COMMIT_TAG).

Tag formats

Tag	Sens	Channel
X.Y.Z	Release prod	production
X.Y.Z-staging.N	Release staging	staging

Pas de préfixe v (Capgo et d'autres outils Spektrum exigent le format Capgo-compatible MAJOR.MINOR.PATCH[-metadata]).

Choix des composants par cas d'usage

Besoin du projet	Composants à inclure
Pousser le tag + badges, c'est tout (lib npm, CLI, scripts…)	release-tag + release-badges
Publier une image Docker	publish-docker seul
Jobs aval déclenchés par tag (Capgo OTA, Fastlane, déploiement K8s gated…)	release-tag + release-badges + release-detect + jobs propres au projet
Image Docker plus jobs aval gated sur tag	publish-docker + release-detect

⚠️ Ne pas combiner publish-docker avec release-tag / release-badges : publish-docker fait déjà le release-util tag et la génération des badges en interne, pour éviter d'enchaîner trois jobs sur le même commit.

Workflow local (rappel)

Côté dev, pour cuter une release :

npx @spektrum/release-util release --env staging   # ou --env prod

Crée la branche release/X.Y.Z[-staging.N] et la MR vers trunk avec le commit chore(release): …. Une fois la MR mergée, les composants CI prennent le relais — le développeur n'a rien d'autre à faire localement.

Voir aussi

• setup.md : variables CI/CD et settings GitLab à préparer une fois par projet.
• troubleshooting.md : symptômes courants et leurs causes.

Contributors

No contributors

Changelog

No recent changes