Domaines

haw compose, orchestre et livre le changement à travers de nombreux dépôts Git — dans n’importe quel domaine. Rien dans le manifeste, le lockfile, le flux de changeset, le build/test à l’échelle de la flotte, ou les hooks de gouvernance n’est spécifique à un secteur. Un dépôt est un dépôt ; un build est n’importe quelle commande shell que vous déclarez ; une PR est une PR.

Cette page montre comment la même boucle —

composer (manifeste) → épingler (lock) → modifier (changeset) → build/test → gouverner (hooks + evidence)

— se projette sur cinq mondes différents. L’embarqué/automobile est un cas de preuve parmi plusieurs, pas l’identité de haw.

Chaque section nomme la difficulté, puis la correspondance. Des manifestes illustratifs se trouvent sous examples/.

Microservices backend

La difficulté. Une seule fonctionnalité visible par l’utilisateur s’étend sur quatre services et un dépôt protobuf/lib partagé. Vous créez une branche pour chacun à la main, ouvrez quatre PR, et essayez de vous souvenir de les fusionner dans le bon ordre sans casser main. Il n’existe aucun artefact unique qui dise « ces cinq SHA constituent la fonctionnalité ».

Comment haw se projette :

• Manifeste / lock. Déclarez les services plus le dépôt proto partagé ; committez haw.lock afin que la CI et chaque coéquipier résolvent l’ensemble identique de SHA.
• Changeset. haw change start FEAT-42 --repos api,billing,proto crée une branche unique à travers exactement les dépôts que la fonctionnalité touche ; haw change request ouvre les PR liées, haw change status agrège la revue + la CI, et haw change land les fusionne dans l’ordre deps (proto avant ses consommateurs).
• Build / test. Chaque service déclare ses propres build/test (cargo, go test, npm test, ./gradlew) ; haw build -j N les déploie en parallèle et se termine avec un code non nul si l’un échoue — intégrez-le directement dans un pipeline.
• Gouverner. Une porte pre-request peut appliquer une politique (scan de secrets, vérification de licence) avant l’ouverture de toute PR.

Voir examples/microservices/.

Plateformes ML / données

La difficulté. Un dépôt de modèle, le dépôt de pipeline de données qui l’alimente, et le dépôt d’infra de service qui le déploie dérivent l’un par rapport à l’autre. Reproduire « le modèle qui était en production en mars » revient à deviner quel commit du pipeline l’a produit.

Comment haw se projette :

• Manifeste / lock. Épinglez ensemble les dépôts de modèle, de pipeline et de service à des SHA exacts. Le lockfile committé est la référence reproductible — un clone des mois plus tard résout les trois mêmes arborescences.
• Stacks / overlays. Un stack training et un stack serving peuvent partager le dépôt de pipeline sans duplication ; un overlay suit main pour le modèle tandis que tout le reste demeure épinglé.
• Build / test. Déclarez test = "pytest" sur le pipeline, build = "dvc repro" ou une commande d’entraînement sur le modèle, et un plan/apply d’infra sur le service — haw fait appel au shell, il n’embarque jamais de chaîne d’outils.
• Gouverner. Les hooks SBOM + provenance enregistrent exactement quels SHA de modèle, de données et d’infra ont été livrés ensemble — la piste d’audit d’une release ML.

Voir examples/ml-platform/.

Plateforme / infra

La difficulté. Les modules racines Terraform, les sous-modules réutilisables et les charts Helm vivent dans des dépôts séparés. Un changement d’un module partagé nécessite des montées de version coordonnées sur chaque consommateur, et « ce qui a été déployé » est réparti sur N dépôts à N révisions.

Comment haw se projette :

• Manifeste / lock. Composez les dépôts de modules et de charts en une seule flotte épinglée ; le lock est l’enregistrement de la référence déployée.
• Changeset. Montez la version d’un module partagé et de ses consommateurs sur une branche unique à travers les dépôts, ouvrez leurs PR ensemble, et fusionnez dans l’ordre des dépendances.
• Build / test. Déclarez test = "terraform validate" / "helm lint" et une commande build/plan par dépôt ; haw test exécute les vérifications de toute la flotte en parallèle.
• Gouverner. haw verify (sortie 3 en cas de dérive) est une porte de CI qui échoue si l’arborescence extraite ne correspond plus à la référence d’infra épinglée.

Voir examples/microservices/ pour le motif de changeset — la même forme s’applique aux dépôts Terraform/Helm.

Mobile

La difficulté. Un dépôt d’application dépend d’un dépôt de SDK interne. Une fonctionnalité nécessite un changement dans les deux, publiés de concert, mais les deux dépôts ont des branches, des PR et une CI indépendantes.

Comment haw se projette :

• Manifeste / lock. Épinglez ensemble les dépôts de l’application et du SDK ; le lock garantit que l’application se compile contre le commit exact du SDK testé.
• Changeset. Une branche à travers application + SDK, des PR liées entre elles, fusionnées SDK d’abord via deps.
• Build / test. Déclarez les commandes Gradle/Xcode/fastlane par dépôt ; haw build pilote les deux.
• Gouverner. Les hooks de signature + SBOM capturent ce qui a été livré dans une release.

Embarqué & automobile

La difficulté. Un HAL/BSP/MCAL partagé est réutilisé sur de nombreux ECU ; la configuration AUTOSAR vit dans des dépôts ARXML qui doivent rester épinglés à côté du code ; et l’ensemble doit être reproductible et auditable pour la qualification de sécurité fonctionnelle.

Comment haw se projette :

• Manifeste / lock. Épinglez BSW/MCAL à des tags/SHA exacts et épinglez les dépôts de config ARXML AUTOSAR dans le lock à leurs côtés — la référence est la preuve d’audit, reproductible octet par octet des années plus tard.

• Stacks / overlays. Plusieurs ECU (gateway, body, …) partagent une seule fondation BSW+MCAL sous forme de stacks séparés, sans duplication ; les overlays échangent les révisions d’une variante sans réécrire la liste des dépôts.

• Changeset. Un correctif inter-ECU se branche à travers les dépôts affectés et fusionne dans l’ordre deps (le logiciel de base avant les applications ECU qui en dépendent).

• Build / test — indépendant de la chaîne d’outils. haw fait appel au shell pour la commande build/test déclarée par dépôt et n’embarque aucun compilateur. Cela signifie qu’il pilote ce que le dépôt déclare :

  • les étapes de configuration + génération Vector MICROSAR / DaVinci,
  • les générateurs Elektrobit (EB) tresos,
  • les compilateurs Green Hills (MULTI / ccrh, …), IAR (iccarm), Tasking, Wind River Diab, et arm-none-eabi-gcc. Chacun est nommé dans le build = / test = de ce dépôt ; haw n’en embarque et n’en exige jamais aucun.

• Gouverner — correspondance avec les normes. Les hooks de gouvernance se projettent directement sur le travail normatif :

  Norme / artefact	Comment haw la couvre
  Automotive SPICE (ASPICE)	haw-aspice émet une traçabilité dépôt → SHA épinglé → domaine de processus
  MISRA C	haw-misra exécute cppcheck --addon=misra à travers la flotte comme une porte pre-request
  ISO 26262 / DO-178C	haw evidence regroupe (manifeste + lock + audit + status) plus SBOM + provenance provenant des plugins de gouvernance
  AUTOSAR ARXML	les dépôts de config épinglés à des SHA exacts dans haw.lock, versionnés avec le code qu’ils configurent

Voir examples/automotive/ et examples/automotive-pinned/.

Le fil conducteur

Sur les cinq, les pièces mobiles sont identiques — seuls les dépôts et les commandes build/test déclarées changent :

Un seul binaire, une seule boucle, tous les domaines.