Krizaka
Toutes les briques

krizaka-build

Build, BOM & kit de test

Le POM parent, le BOM et les tests de gouvernance derrière chaque artefact com.krizaka.

Le problème qu'elle supprime

Les POM parents dérivent — et un BOM Spring écrase en silence la version de Boot choisie.

Toute organisation Java multi-dépôts finit avec des POM parents qui dérivent : un module sur un autre Java, des plugins non figés, un POM que Maven Central refuse faute de bloc de licence. Et un BOM qui importe celui de Spring écrase en silence la version de Spring Boot que vous aviez choisie.

  • Des conventions dans un wiki : vraies le jour où on les écrit.
  • Une configuration Testcontainers par dépôt, chacune démarrant sa base par classe de test.
  • Une version mineure qui casse la compatibilité binaire, découverte par ceux qui ont mis à jour.

Ce qu'elle fait

  • krizaka-parent : Java 21, plugins figés, métadonnées Central, une release signée en une commande.
  • krizaka-bom : l'ensemble compatible de tout artefact com.krizaka, et rien d'autre.
  • krizaka-test-support : règles d'architecture, vrais PostgreSQL + RabbitMQ, tests de contrat d'événements.

krizaka-parent (métadonnées Central, Java 21, formatage vérifié, tests unitaires et d'intégration, couverture, une release signée en une commande), krizaka-bom (l'ensemble compatible de tout artefact com.krizaka) et krizaka-test-support (règles d'architecture, un PostgreSQL + RabbitMQ par exécution de tests, tests de contrat d'événements).

Une règle qui ne juge rien ne laisse rien passer. Chaque règle du kit de test échoue sur une population vide — une faute de frappe dans un nom de package ne peut pas transformer un contrôle en coche verte.

La règle du canard

Décisions et compromis

  1. Nous avons choisi

    Un BOM qui ne porte que des artefacts com.krizaka ; le parent n'a pas de dependencyManagement à lui.

    Nous avons refusé

    Importer spring-boot-dependencies dans notre BOM.

    Parce que

    Importer krizaka-bom ne doit jamais figer une version que vous avez choisie. Votre BOM Spring Boot reste le vôtre ; le nôtre se pose à côté.

    Ce que cela vous coûte

    Vous importez vous-même le BOM (ou le parent) de Spring Boot.

  2. Nous avons choisi

    Les règles d'architecture en tests (CodeRules, SourceRules, ConfigBindingRules : couches, injection par constructeur, état privé, pas d'injection d'Environment…).

    Nous avons refusé

    Une check-list de revue.

    Parce que

    Une règle exécutée à chaque build est la seule encore vraie six mois plus tard.

    Ce que cela vous coûte

    Les règles ont des opinions : prenez celles qui vous vont, appelez-les depuis votre propre test.

  3. Nous avons choisi

    japicmp dans le profil release : une rupture binaire dans une mineure fait échouer la release ; publication sur Central confirmée à la main.

    Nous avons refusé

    Le SemVer de bonne volonté, et la publication automatique.

    Parce que

    Une release sur Central ne s'efface jamais : une rupture livrée l'est pour toujours.

    Ce que cela vous coûte

    Une rupture volontaire se déclare dans le dépôt pour cette release.

En code

javaNotificationRequestContractTest.java
// krizaka-test-support: the producer proves its event matches the JSON Schema its -api publishes
// (events/evt.notification.requested.v1.json, draft 2020-12). A consumer checks its own copy
// against the same file with assertReadable — no shared DTO jar between services.
class NotificationRequestContractTest extends EventContractTest {

  @Test
  void anEmailRequestConforms() {
    assertConforms(NotificationRouting.NOTIFICATION_REQUESTED, 1,
        new NotificationRequest(Channel.EMAIL, "ada@example.com", "welcome", "fr-FR",
            Map.of("name", "Ada")));
  }
}

Ne l'utilisez pas quand

  • Vous ne publiez pas sur Maven Central et ne voulez pas nos conventions (google-java-format, Java 21) dans votre build : importez le BOM, laissez le parent.
  • Vous êtes en Java 17 ou avant.

Où elle en est

0.2.0 sur Maven Central : krizaka-parent, krizaka-bom, krizaka-test-support (avec EventContractTest).

Publié

En cours

  • Le BOM 0.2.0 nomme users, notifications et billing en 0.2.0, pas encore publiée. Décidé : une release du BOM résout chaque artefact qu'elle gère avant d'être signée ; le BOM 0.3.0 attend les trois.krizaka-build#11

L'adopter

xmlpom.xml
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.krizaka</groupId>
      <artifactId>krizaka-bom</artifactId>
      <version>0.2.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependency>
  <groupId>com.krizaka</groupId>
  <artifactId>krizaka-test-support</artifactId>
  <scope>test</scope>
</dependency>

Dites-nous où ça coince.

Une brique est juste quand elle survit à votre code, pas au nôtre. Posez votre question dans le fil de la brique, proposez un changement comme idée, ou signalez un bug sur son dépôt — chaque décision de cette page reste ouverte à un meilleur argument.

Les autres briques