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 artefactcom.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.
Décisions et compromis
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-dependenciesdans notre BOM.Parce que
Importer
krizaka-bomne 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.
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.
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
// 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é
com.krizaka:krizaka-bom · krizaka-parent 0.2.0 · Maven Centralcom.krizaka:krizaka-test-support 0.2.0 · Maven CentralEn 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
<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
- Platform kitUn événement publié après le commit se perd au prochain crash.
- UtilisateursL'inscription ressemble à un week-end. Jetons de reset, OAuth et JWT en font un trimestre.
- NotificationsUn e-mail envoyé dans une transaction annulée ne se rattrape pas.
- Facturation & créditsDébiter après, et le travail tourne à crédit. Débiter avant, et les échecs sont facturés.
- Krizaka UITrois produits, trois vocabulaires de jetons, 1 153 surcharges
light:dans une seule app.