ModularPipelines: CI/CDパイプラインをC#モジュールとして書く

このプロジェクトが出発点とするYAMLの問題

READMEはYAMLパイプラインに対する4つの不満から始まる。ローカルでデバッグできない、変数名のタイプミスがコンパイルエラーではなく遅いフィードバックループを生む、ロジックの再利用がYAMLの複数箇所への重複を意味する、GitHub ActionsからAzure Pipelinesへの移行で設定を書き直す必要がある。ModularPipelinesはその代替として提示されている。パイプラインは通常のC#コードとして書かれ、dotnet runで実行される。READMEはC#がこれらの問題をすべて取り除くとは主張しておらず、コードベースのアプローチがエラーの検出場所を変える、つまりプッシュ前にIDEで検出されると述べている。

作業単位としてのモジュール

パイプラインの各ステップは、ModuleまたはModule<T>を継承するモジュールクラスである。依存関係は属性で宣言される。たとえば公開モジュールに[DependsOn<BuildModule>]を付ける。READMEによれば、フレームワークはこれらの宣言から並列実行できる処理を計算してスケジュールするため、開発者が並列ジョブを手作業で調整する必要はない。循環依存の検出も組み込み機能として挙げられている。各作業単位を独自のクラスに分けることがREADMEが記載するアーキテクチャ上の選択であり、マージ競合が減り、分離したテストが可能になるとされている。

モジュール間で強く型付けされたデータを受け渡す

モジュールは型付きの結果を返せる。READMEでは、バージョンと出力パスを持つBuildInfoオブジェクトを返すBuildModuleと、context.GetModule<BuildModule>()でそのオブジェクトを取得するPublishModuleが示されている。READMEはこれを、共有された可変状態を持たないクリーンなデータフローと説明する。結果が利用できないモジュールに対してGetModuleを呼ぶと、モジュールコンテキストを伴う例外が投げられるとREADMEは述べている。例外の型と並行実行時の挙動はREADMEには詳述されていない。

コンパイル時チェックと開発者のワークフロー

このリポジトリにはRoslynアナライザーが含まれており、GetModule<T>()を呼ぶ際の[DependsOn]属性の欠落、循環依存、待機されていないモジュール結果、ログシステムを使うべきConsole.Write呼び出しを指摘する。READMEはまた、ASP.NET Coreのパターンに従う完全な依存性注入、ログ内のシークレットの自動難読化、モジュールへの参照をすべて更新する名前変更リファクタリングなどのIDEサポートについても説明している。READMEは特定のIDEを挙げておらず、パイプラインコードがアプリケーションコードと同じ扱いを受けると述べている。

テンプレートまたはパッケージ参照によるセットアップ

クイックスタートでは、dotnet new install ModularPipelines.Templatesでテンプレートパッケージをインストールし、dotnet new modularpipelineでパイプラインプロジェクトを作成し、dotnet runで実行する。生成されたプロジェクトには、明示的な依存関係を持つrestore、build、test、publishの各モジュールが含まれる。既存プロジェクトの場合は、READMEにdotnet add package ModularPipelinesとModularPipelines.DotNetが挙げられ、Pipeline.CreateBuilderでパイプラインを構築してExecutePipelineAsyncを待機するProgram.csが示されている。コピーしてそのまま使える完全な例としてテンプレートソースが参照されている。

ツールラッパーとCake・Nukeとの比較

統合テーブルには、Docker、dotnet、git、Terraform、Kubernetes、Helm、Slack、Amazon Web Services、Azureなどを含む40のパッケージが、強く型付けされたラッパー付きで並んでいる。別の比較テーブルはModularPipelinesをCakeおよびNukeと位置づける。実際のC#、依存関係に基づく自動並列化、分離されたモジュールクラス、Microsoft.Extensions.DIを主張し、Cakeは手動並列化のC# DSL、Nukeは単一のビルドクラスを持つ実際のC#と説明されている。READMEはこれらの位置づけについてベンチマークや第三者による検証を提供していない。

ライセンスと安定性の注意点

リポジトリのメタデータはMIT SPDXライセンスを記録しているが、確認した資料にライセンスファイル自体は含まれておらず、具体的な許諾条件をここで引用することはできない。READMEは、マイナーバージョンに破壊的変更が含まれる可能性があり、それらはリリースノートに記録されると述べている。READMEはセキュリティ保証、サポートの約束、保証条件については説明していない。リポジトリのメタデータは56件の未解決Issueを挙げているが、READMEはそれらの内容を説明していない。

既存の YAML を移す前に、テンプレートが生成する restore、build、test、publish の依存グラフを一度そのまま実行し、どのモジュールが並列化されるかをログで確認します。次に BuildInfo のような型付き結果を PublishModule が受け取る例を小さく変更し、Roslyn アナライザーが DependsOn の欠落、未 await、循環依存を検出するかを確認します。dotnet new install ModularPipelines.Templates と dotnet run が動く SDK 条件、既存プロジェクトで追加する ModularPipelines.DotNet の版を固定してください。README はマイナーバージョンの破壊的変更があり得ると記すため、Cake や Nuke からの移行では構文の好みだけでなくリリース単位の追随コストを見積もります。

編集部の結論

ModularPipelinesはYAMLパイプラインファイルをC#モジュールクラスに置き換え、自動並列化、Roslynアナライザー、ローカルデバッグを文書化された利点として挙げている。リポジトリのメタデータはMITライセンスを示すが、確認した資料にライセンス文書自体は含まれておらず、READMEはマイナーバージョンに破壊的変更が含まれる可能性がありリリースノートに記録されると述べている。

公式情報源

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