Vos modules évoluent.
Leur responsabilité reste claire.
Une version, un paramètre ou un plugin ne crée pas automatiquement un nouveau module. Commencez par la capacité existante et identifiez précisément ce qui change.
Réutiliser, paramétrer, adapter, puis créer si nécessaire
- RéutiliserLe besoin entre déjà dans le contrat publié. Le projet compose les capacités existantes.
- ParamétrerUne version ou une option compatible est exposée par la recette. Le choix est versionné dans la configuration client.
- Adapter et versionnerLa même responsabilité a besoin d’une extension. Son contrat et son implémentation évoluent avec leurs tests de compatibilité.
- Créer une capacitéUne responsabilité absente justifie un nouveau module. Ses dépendances, opérations, entrées et preuves sont définies avant publication.
Une base Node partagée reste N1-NODE : les versions et options compatibles ne deviennent pas des modules par application. Le même principe vaut pour PHP, les services et les ressources. Une rupture d’un même contrat exige d’abord une nouvelle version majeure ; elle ne crée pas automatiquement une nouvelle responsabilité.
Votre fork, vos thèmes et votre code métier restent dans le dépôt livré. La plateforme construit ce code ; une adaptation de recette ne le remplace pas par une archive officielle pour réussir l’installation.
Ce qui se personnalise à chaque niveau
| Niveau | Changements possibles | Ce qui exige une évolution ou une preuve nouvelle |
|---|---|---|
| N0 · Ressources | Enveloppe du conteneur, image et plateforme publiées, demande d’allocation, montages et droits des volumes. | Nouvelle architecture, autre mode de stockage, agrandissement physique ou restauration. Modifier une demande de capacité ne prouve pas le resize du volume. |
| N1 · Environnements | Versions compatibles, commandes, dépendances verrouillées, chemins, extensions PHP, répertoire public, tâches périodiques et composition pris en charge. | Nouveau runtime, nouveau mode d’exécution ou migration majeure non couverte. Les dépendances doivent être présentes et contrôlées à la construction. |
| N2 · Services | Moteur prévu par la recette, binding autorisé, identité et paramètres de service dans le contrat publié. | Substitution de moteur, migration majeure, haute disponibilité, nouvelle livraison SMTP ou restauration. Un binding vers un fournisseur existant ne prouve pas un provisionnement de serveur neuf. |
| N3 · Applications | Code métier, thème, plugin et configuration compatibles dans le dépôt client ; version applicative admise par la recette. | Nouveau besoin de runtime ou de service, migration incompatible, plugin hors scénario ou autre fonction non exercée. La qualification doit couvrir ce changement. |
La fiche de chaque module expose ses entrées, paramètres, dépendances et consommateurs. Les entrées du contrat de capacité ne sont pas toutes des clés à copier dans paas.toml.
Des adaptations concrètes à plusieurs niveaux
Un thème WordPress
Le thème et ses dépendances restent dans votre dépôt. Si PHP, MySQL et les chemins persistants existants couvrent son besoin, le projet réutilise les mêmes modules. Le thème repasse les contrôles et ses fonctions sont vérifiées ; il n’hérite pas automatiquement de la qualification du scénario WordPress.
Faire évoluer PHP pour plusieurs applications
FreshRSS a ajouté les paramètres SQLite, bibliothèques du dépôt, répertoire public et tâche périodique. Les adaptations suivantes couvrent notamment les proxys de confiance pour PrestaShop, le traitement des noms de fichiers pour Joomla et les images pour TYPO3. Ces options appartiennent à N1-PHP et à ses recettes ; chaque évolution repasse ses tests et ceux des consommateurs concernés.
Réutiliser un service avec une variante explicite
ERPNext utilise une variante MariaDB réservée de N2-MYSQL. Discourse et Immich utilisent des profils PostgreSQL avec extensions admises. Ces paramètres ne créent pas un service N2 par application. Ils ne qualifient ni la conversion d’une base MySQL existante vers MariaDB, ni une migration majeure de PostgreSQL.
Ajouter un runtime ou un service distinct
Metabase a besoin du runtime JVM ; Discourse et Redmine partagent Ruby. Plausible compose Elixir et ClickHouse avec les modules existants. JVM, Ruby, Elixir et ClickHouse sont des responsabilités réutilisables ; leurs versions et paramètres restent dans leurs contrats respectifs.
Conserver les ressources N0
Les nouvelles recettes réutilisent les conteneurs, volumes et allocations existants. Les identités et données sont vérifiées pendant les mises à jour indiquées ; une demande de stockage différente ne prouve ni un agrandissement physique ni une restauration.
Conserver une configuration client, produire les fichiers nécessaires
paas.toml reste l’entrée éditable de l’installation. La recette peut produire une configuration applicative compilée, comme BookStack, pour appliquer sans ambiguïté les paramètres et les accès du projet. Cette sortie ne devient pas une seconde configuration à maintenir à la main.
NodeBB réutilise Node, MongoDB, la persistance et la composition. Sa liaison MongoDB propre au projet n’ouvre aucun accès à l’inférence et ne lui ajoute ni Redis ni PostgreSQL. Les assets et sorties de plugins qui doivent être écrits au démarrage utilisent la zone privée prévue par la recette, tout en conservant les sources livrées en lecture seule.
Les données métier et les sorties régénérables ont des règles de conservation distinctes. Une personnalisation qui change ces chemins, ajoute un plugin ou exige un service supplémentaire doit être admise par le contrat et vérifiée ; elle n’hérite pas automatiquement des preuves NodeBB.
Le changement suit le même parcours Git
- Décrivez le comportement attendu et les données à conserver.
- Identifiez le module responsable et la portée actuellement vérifiée.
- Versionnez votre configuration et le code complet, avec des dépendances verrouillées.
- Exécutez construction, tests, contrôles de sécurité et admission sur le commit exact.
- Vérifiez le service rendu, les nouvelles fonctions et, en mise à jour, l’identité et les données existantes.
Si une option n’est pas admise ou qu’une capacité est absente, le diagnostic conserve la cause. Une évolution autorisée de la capacité est nécessaire avant la reprise. La réparation automatique de configuration ne peut pas inventer un runtime ni modifier le code métier du client. Une dépendance vulnérable peut nécessiter un vrai push de maintenance dans votre Git ; elle ne disparaît pas en changeant le TOML.
Après une correction produit ou une configuration revue, le même incident reprend avec ses refus et son budget consommé. Un push compatible ultérieur peut passer sans modèle ; cette propriété ne qualifie ni une personnalisation arbitraire ni une migration amont.
Changer la configuration ne remplace pas les preuves. Une sauvegarde réussie n’établit pas une restauration ; une mise à jour d’application n’établit pas la migration du moteur ; une nouvelle quantité de stockage ne prouve pas l’agrandissement physique.