バージョン管理 & Build

独立したバージョン管理

Lino プロジェクトには複数のサービスと Web アプリケーションを含めることができます。各デプロイ可能項目は独自のバージョンを持つため、1 つのサービスの小さな修正がシステム全体の不自然な release を強制することはありません。これは、API、workers、web apps、migrations、統合契約が異なる速度で進化するモジュール型および分散アーキテクチャで重要です。

運用上のバージョンは version.txt という単純なテキストファイルに保存されます。サービスでは src/Services/<ServiceName>/version.txt に配置されます。Web アプリケーションでは src/WebApps/<WebAppName>/version.txt に配置されます。Lino CLI は、一覧表示、参照、インクリメント、バージョン付き build の生成時にこれらのファイルを読み取ります。

Lino が使用する SemVer ルール

MAJOR.MINOR.PATCH

• PATCH は最後の番号を増やし、互換性のある修正、小さな内部改善、公開 contract を変更しない変更に使用します。
• MINOR は中央の番号を増やし、patch を 0 に戻します。後方互換性のある機能、新しい endpoints、任意項目、または追加的な振る舞いに使用します。
• MAJOR は最初の番号を増やし、minor と patch を 0 に戻します。API contract が非互換に変更された、または振る舞いが意図的に置き換えられたなど、利用側が対応する必要がある場合に使用します。

例: 1.0.0 は最初の安定版、1.0.1 は互換性のある修正、1.1.0 は互換性のある新機能または破壊的変更のない新しい endpoints、2.0.0 はクライアント更新が必要な変更を含む release を表せます。

現在のバージョンを確認する

プロジェクト内のすべてのサービスと Web アプリケーションの現在バージョンを見るには lino version list を使用します:

lino version list

特定のサービスまたは Web アプリケーションのバージョンを確認する必要がある場合は lino version show を使用します。このコマンドは対象がサービスか Web アプリケーションかを尋ね、対応する version.txt ファイルから読み取ったバージョンを表示します。

lino version show

バージョンを上げる

サービスまたは Web アプリケーションが新しい release の準備ができたら lino version bump を使用します:

lino version bump

1. プロジェクトのルートからコマンドを実行します。
2. 1 つ以上のサービスまたは Web アプリケーションを選択します。プロンプトには各項目と現在のバージョンが表示されます。
3. インクリメント種別を選択します: patch、minor、major。
4. 回答を確認します。Lino は選択された version.txt ファイルを更新し、新しいバージョンを含む表を表示します。

各実行により変更の追跡が明確になり、release プラクティスとの一貫性が向上し、CI/CD pipelines との整合が容易になります。バージョン番号は単なる孤立した詳細ではなく、実際に変更されたデプロイ可能アーティファクトを識別するものになります。

バージョン変更は release の技術的影響とあわせてレビューする必要があります。データベース migration がサービスバージョンに紐づく場合があり、API 利用者には contract notes が必要になることがあり、統合イベントには互換性チェックが必要になることがあります。バージョンをデプロイ可能項目の近くに保つことで、これらの判断が明示的になり、監査しやすくなります。

major インクリメントの前には、公開 API、イベント contract、migrations、クライアント互換性、外部利用者を確認します。minor インクリメントの前には、新しい振る舞いが追加的であることを確認します。patch の前には、変更が互換性を保ち、利用上の期待を変えないことを確認します。

Build とコンテナ化

動画や日々の開発では、各モデリング手順の後でも生成されたソリューションがコンパイルできることを検証するために dotnet build がよく使用されます。lino build コマンドの目的は別です。選択されたサービスと Web アプリケーションを、.NET の container publish profile を使って Release モードで公開し、release の準備をします。

この分離により、単なるコンパイル検証を配布パッケージとして扱うことを避けられます。開発中は早期にエラーを見つけるために dotnet build を使用します。アーティファクトにバージョンを付け、container image にし、registry または deploy pipeline に進める準備ができたときに lino build を使用します。

lino build が行うこと

Lino プロジェクトのルートからコマンドを実行します:

lino build

CLI は認証済みユーザーと現在のプロジェクト設定を検証し、どのサービスまたは Web アプリケーションを build に含めるかを尋ね、その後バージョンを維持するかインクリメントするかを尋ねます。インクリメントが選択されると、Lino は build コマンドを生成する前に対応する version.txt を更新します。

backend は実行すべき正確なコマンドを返します。現在、これらのコマンドは dotnet publish に -c Release、-p:PublishProfile=DefaultContainer、-p:ContainerRepository、-p:ContainerImageTag、-p:ContainerLabelVersion を指定して使用します。image tag と container の version label には、release に選択された同じ SemVer 値が設定されます。

実際には、このプロセスはサービスまたは Web アプリケーションのコードをコンパイルし、必要な公開設定を適用し、現在の SemVer バージョンに基づく container image を生成し、アーティファクトに標準化された名前、tag、メタデータを付与します。

生成される repository 名

Lino はプロジェクト名と項目名を正規化し、予測可能な container repository を生成します:

• 単純なサービス API: <project-name>/services/<service-name>-api:1.2.3
• モジュール型サービス host: <project-name>/services/<service-name>-host:1.2.3
• Blazor Web アプリケーション: <project-name>/webapps/<webapp-name>:1.2.3

この規約により、サービス API、モジュール型 hosts、Web アプリケーションは registry 内で分離され、release バージョンは tag に保持されます。このパターンは繰り返しの手作業判断を減らし、環境、CI/CD scripts、運用ドキュメント間の差異も抑えます。

Registries への公開

生成された images は、deploy プラットフォームで使用する registry に公開できます:

• Docker Hub
• GitHub Container Registry
• AWS ECR
• Azure Container Registry
• その他の OCI 互換 registry。

可能な限り、floating tags ではなく 1.2.3 のような不変のバージョン tag を参照して deploy します。これにより rollback、監査、build・公開・deploy された内容の比較が改善されます。

推奨 release フロー

1. パッケージ化の前に、プロジェクトのテストと dotnet build を実行してソースコードを検証します。
2. lino version list で現在のバージョンを確認し、どのサービスまたは Web アプリケーションが変更されたかをレビューします。
3. lino build を使用し、現在のバージョンを維持するか、patch、minor、major のインクリメントを適用するかを選択します。
4. 生成された container images を、Docker Hub、GitHub Container Registry、AWS ECR、Azure Container Registry、または別の互換 registry など、deploy プラットフォームで使用する registry に公開します。
5. 追跡可能なバージョン tag を参照して deploy し、changelog、migrations、rollback plan を同じ release に結び付けます。

secrets、本番 connection strings、環境固有の認証情報を生成された images に入れないでください。環境変数、ローカル開発用の user secrets、CI/CD の secret vault、または deploy プラットフォームの secret 機構を使用します。

このフローにより、バージョン管理と build は結び付いたままになります。プロジェクトに記録された同じ SemVer 値が container tag と release metadata として使われ、ソースコード、migrations、API contracts、統合イベント、デプロイ済みアーティファクト間のトレーサビリティが向上します。