Versionnement & Build

Versionnement indépendant

Les projets Lino peuvent contenir plusieurs services et applications web. Chaque élément déployable possède sa propre version, ce qui évite qu'une petite correction dans un service force un release artificiel de tout le système. C'est important dans les architectures modulaires et distribuées, où APIs, workers, web apps, migrations et contrats d'intégration peuvent évoluer à des rythmes différents.

La version opérationnelle est stockée dans un simple fichier texte nommé version.txt. Pour les services, le fichier se trouve dans src/Services/<ServiceName>/version.txt. Pour les applications web, il se trouve dans src/WebApps/<WebAppName>/version.txt. Le CLI Lino lit ces fichiers lors de la liste, de la consultation, de l'incrémentation et de la génération de builds versionnés.

Règle SemVer utilisée par Lino

MAJOR.MINOR.PATCH

• PATCH incrémente le dernier nombre et doit être utilisé pour les corrections compatibles, les petites améliorations internes et les changements qui ne modifient pas le contrat public.
• MINOR incrémente le nombre du milieu et remet patch à zéro. Utilisez-le pour des fonctionnalités rétrocompatibles, de nouveaux endpoints, des champs optionnels ou un comportement additif.
• MAJOR incrémente le premier nombre et remet minor et patch à zéro. Utilisez-le lorsque les consommateurs doivent s'adapter, par exemple parce qu'un contrat d'API a changé de manière incompatible ou qu'un comportement a été remplacé intentionnellement.

Exemples : 1.0.0 peut représenter la première version stable, 1.0.1 une correction compatible, 1.1.0 une nouvelle capacité compatible ou de nouveaux endpoints sans rupture, et 2.0.0 un release avec des changements qui exigent une mise à jour des clients.

Consulter les versions actuelles

Utilisez lino version list pour voir les versions actuelles de tous les services et applications web du projet :

lino version list

Utilisez lino version show lorsque vous devez consulter la version d'un service ou d'une application web spécifique. La commande demande si la cible est un service ou une application web et affiche la version lue dans le fichier version.txt correspondant.

lino version show

Incrémenter une version

Utilisez lino version bump lorsqu'un service ou une application web est prêt pour un nouveau release :

lino version bump

1. Exécutez la commande depuis la racine du projet.
2. Sélectionnez un ou plusieurs services ou applications web. Le prompt affiche chaque élément avec sa version actuelle.
3. Choisissez le type d'incrément : patch, minor ou major.
4. Confirmez les réponses. Lino met à jour les fichiers version.txt sélectionnés et affiche un tableau avec les nouvelles versions.

Chaque exécution conserve un suivi clair des changements, améliore la cohérence avec les pratiques de release et facilite l'alignement avec les pipelines CI/CD. Le numéro de version cesse d'être un détail isolé et commence à identifier l'artefact déployable qui a réellement changé.

Les changements de version doivent être revus avec l'impact technique du release. Une migration de base de données peut être liée à la version d'un service, les consommateurs d'API peuvent avoir besoin de notes de contrat et les événements d'intégration peuvent exiger des contrôles de compatibilité. Garder la version proche de l'élément déployable rend ces décisions explicites et plus faciles à auditer.

Avant un incrément major, révisez les APIs publiques, les contrats d'événements, les migrations, la compatibilité des clients et les consommateurs externes. Avant un incrément minor, confirmez que le nouveau comportement est additif. Avant un patch, confirmez que le changement est compatible et ne modifie pas les attentes d'utilisation.

Build et conteneurisation

Dans les vidéos et le développement quotidien, dotnet build est souvent utilisé pour vérifier que la solution générée compile encore après chaque étape de modélisation. La commande lino build a un autre objectif : préparer les services et applications web sélectionnés pour release, en les publiant en mode Release avec le profil de publication de container .NET.

Cette séparation évite de traiter une simple validation de compilation comme un paquet de livraison. Utilisez dotnet build pendant le développement pour détecter les erreurs tôt. Utilisez lino build lorsque l'artefact est prêt à recevoir une version, devenir une image de container et partir vers un registry ou un pipeline de déploiement.

Ce que fait lino build

Exécutez la commande depuis la racine d'un projet Lino :

lino build

Le CLI valide l'utilisateur authentifié et la configuration actuelle du projet, demande quels services ou applications web doivent entrer dans le build, puis demande si la version doit être conservée ou incrémentée. Lorsqu'un incrément est sélectionné, Lino met à jour le version.txt correspondant avant de générer les commandes de build.

Le backend renvoie les commandes exactes à exécuter. Actuellement, ces commandes utilisent dotnet publish avec -c Release, -p:PublishProfile=DefaultContainer, -p:ContainerRepository, -p:ContainerImageTag et -p:ContainerLabelVersion. La tag de l'image et le label de version du container reçoivent la même valeur SemVer choisie pour le release.

En pratique, le processus compile le code du service ou de l'application web, applique la configuration de publication nécessaire, génère une image de container basée sur la version SemVer actuelle et attribue à l'artefact un nom, une tag et des métadonnées standardisés.

Noms de repository générés

Lino normalise les noms du projet et des éléments pour générer des repositories de container prévisibles :

• API de service simple : <project-name>/services/<service-name>-api:1.2.3
• Host de service modulaire : <project-name>/services/<service-name>-host:1.2.3
• Application web Blazor : <project-name>/webapps/<webapp-name>:1.2.3

Cette convention garde les APIs de services, les hosts modulaires et les applications web séparés dans le registry, tout en préservant la version de release dans la tag. Le modèle élimine aussi des décisions manuelles répétitives et réduit les divergences entre environnements, scripts CI/CD et documentation opérationnelle.

Publication dans des registries

Les images générées peuvent être publiées dans le registry utilisé par votre plateforme de deploy :

• Docker Hub
• GitHub Container Registry
• AWS ECR
• Azure Container Registry
• tout autre registry compatible OCI.

Chaque fois que possible, faites le deploy en pointant vers des tags de version immuables, comme 1.2.3, plutôt que vers des tags flottantes. Cela améliore le rollback, l'audit et la comparaison entre ce qui a été compilé, publié et déployé.

Flux de release recommandé

1. Exécutez les tests du projet et dotnet build pour valider le code source avant le packaging.
2. Consultez les versions actuelles avec lino version list et révisez quels services ou applications web ont changé.
3. Utilisez lino build et choisissez si la version actuelle sera conservée ou recevra un incrément patch, minor ou major.
4. Publiez les images de container générées dans le registry utilisé par la plateforme de déploiement, comme Docker Hub, GitHub Container Registry, AWS ECR, Azure Container Registry ou un autre registry compatible.
5. Déployez en référençant des tags de version traçables et gardez le changelog, les migrations et le plan de rollback connectés au même release.

Ne placez pas de secrets, de connection strings de production ni d'identifiants spécifiques à un environnement dans les images générées. Utilisez des variables d'environnement, user secrets pour le développement local, des coffres de secrets CI/CD ou le mécanisme de secrets de la plateforme de deploy.

Avec ce flux, versionnement et build restent liés : la même valeur SemVer enregistrée dans le projet est utilisée comme tag de container et comme métadonnée de release, ce qui améliore la traçabilité entre code source, migrations, contrats d'API, événements d'intégration et artefacts déployés.