ModularPipelines : des pipelines CI/CD en modules C#

Les problèmes YAML dont part ce projet

Le README commence par quatre griefs contre les pipelines YAML : impossible de les déboguer localement, les fautes de frappe dans les noms de variables produisent des boucles de retour lentes au lieu d'erreurs de compilation, la réutilisation de la logique impose de dupliquer le YAML à plusieurs endroits, et passer de GitHub Actions à Azure Pipelines oblige à réécrire la configuration. ModularPipelines est proposé comme remplacement. Le pipeline est écrit en C# ordinaire et exécuté avec dotnet run. Le README ne prétend pas que C# élimine tous ces problèmes, seulement que l'approche par code change l'endroit où une erreur est attrapée : dans l'IDE, avant le push.

Les modules comme unité de travail

Chaque étape d'un pipeline est une classe de module qui hérite de Module ou de Module<T>. Les dépendances sont déclarées par attributs, par exemple [DependsOn<BuildModule>] sur un module de publication. Le README indique que le framework calcule ce qui peut s'exécuter en parallèle à partir de ces déclarations et planifie en conséquence, évitant ainsi l'orchestration manuelle des travaux parallèles. La détection des dépendances circulaires est listée comme fonctionnalité intégrée. Le choix architectural que le README met en avant est de placer chaque unité de travail dans sa propre classe, avec moins de conflits de fusion et des tests isolés comme bénéfices annoncés.

Passer des données fortement typées entre modules

Les modules peuvent renvoyer un résultat typé. Le README montre un BuildModule qui renvoie un objet BuildInfo avec une version et un chemin de sortie, et un PublishModule qui le récupère avec context.GetModule<BuildModule>(). Le README décrit cela comme un flux de données propre, sans état mutable partagé. Appeler GetModule pour un module dont le résultat n'est pas disponible lève une exception qui porte le contexte du module, selon le README. Le type exact de l'exception et le comportement en exécution concurrente ne sont pas détaillés dans le README.

Vérifications à la compilation et flux de travail du développeur

Le dépôt inclut des analyseurs Roslyn qui signalent les attributs [DependsOn] manquants lors d'un appel à GetModule<T>(), les dépendances circulaires, les résultats de module non attendus et les appels Console.Write qui devraient utiliser le système de journalisation. Le README décrit aussi une injection de dépendances complète suivant les modèles ASP.NET Core, l'obfuscation automatique des secrets dans les journaux et un support IDE tel que le renommage qui met à jour toutes les références à un module. Le README ne nomme pas d'IDE précis ; il dit que le code de pipeline reçoit le même traitement que le code applicatif.

Installation par modèles ou références de paquets

Le démarrage rapide installe le paquet de modèles avec dotnet new install ModularPipelines.Templates, crée un projet de pipeline avec dotnet new modularpipeline et l'exécute avec dotnet run. Le projet généré contient des modules restore, build, test et publish séparés, avec dépendances explicites. Pour un projet existant, le README liste dotnet add package ModularPipelines et ModularPipelines.DotNet, puis montre un Program.cs qui construit un pipeline avec Pipeline.CreateBuilder et attend ExecutePipelineAsync. La source du modèle est citée pour un exemple complet prêt à copier.

Wrappers d'outils et position face à Cake et Nuke

Le tableau des intégrations liste 40 paquets avec wrappers fortement typés, couvrant Docker, dotnet, git, Terraform, Kubernetes, Helm, Slack, Amazon Web Services et Azure, entre autres. Un tableau comparatif distinct positionne ModularPipelines face à Cake et Nuke : C# réel, parallélisation automatique fondée sur les dépendances, classes de modules séparées et Microsoft.Extensions.DI, tandis que Cake est décrit comme un DSL C# à parallélisation manuelle et Nuke comme du C# réel avec une classe de build unique. Le README ne fournit ni benchmarks ni validation tierce pour ces positions.

Licence et notes de stabilité

Les métadonnées du dépôt enregistrent une licence SPDX MIT, mais le fichier de licence lui-même n'était pas disponible dans les documents examinés, donc les conditions précises d'octroi ne peuvent pas être citées ici. Le README dit que les versions mineures peuvent contenir des changements cassants, documentés dans les notes de version. Le README ne décrit ni garanties de sécurité, ni engagements de support, ni conditions de garantie. Les métadonnées du dépôt listent 56 problèmes ouverts ; le README n'explique pas ce que ces problèmes concernent.

Conclusion éditoriale

ModularPipelines remplace les fichiers de pipeline YAML par des classes de modules C# ; la parallélisation automatique, les analyseurs Roslyn et le débogage local sont les bénéfices documentés. Les métadonnées du dépôt indiquent une licence MIT, mais le texte de la licence n'était pas disponible dans les documents examinés, et le README précise que les versions mineures peuvent contenir des changements cassants documentés dans les notes de version.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes