Octopus Deploy を使ってみた（２）アプリケーションの発行
クロスワープの大鷲です。
前回は特に面白いこともないインストールだけで終わってしまいました。
今回はもう少しだけ技術的な内容です。
アプリケーションのパッケージング
Octopus Deploy では、アプリケーションを NuGet パッケージ形式 (*.nupkg) に固めて、Octopus サーバーにアップロードします。
パッケージを作成する方法は複数ありますが、今回は Visual Studio (MSBuild) との親和性が高い OctoPack を使います。
www.nuget.org
OctoPack
使い方は簡単です。
- アプリケーションのプロジェクトに OctoPack への参照を追加する
- ビルド時の MSBuild のコマンドライン オプションに /p:RunOctoPack=true を追加する
これだけです。
なお、OctoPack はアプリケーションをパッケージングするためのものなので、ソリューション内にクラス ライブラリ プロジェクトとアプリケーション プロジェクトが同居している場合、アプリケーション プロジェクトに追加するだけで構いません（アプリケーション プロジェクトの出力ディレクトリの中身をすべてパッケージングします）。
通常、アプリケーションをデプロイする前のビルドはビルド サーバーで行うでしょう。
ビルド サーバーにはコマンド ライン オプションを指定できる機能がありますから、MSBuild コマンドのオプションに /p:RunOctoPack=true を追加してください。
試しにローカルでパッケージングしてみる場合などは、VS の開発者コマンド プロンプトを開いて MSBuild を叩けばできます。
ビルドすると、出力ディレクトリに <アプリケーション名>.<バージョン>.nupkg というファイルができているはずです。
OctoPack のオプション
最低限必要なオプションは RunOctoPack だけですが、その他にも、パッケージをカスタマイズするためのオプションが多数あります。
詳細は公式ドキュメントの Using OctoPack を参照してください。
config ファイルの変換
Web.config や App.config を使っている場合、環境に応じてそれらを書き換える XML ドキュメント変換を利用している場合も多いと思います。
Octopus Deploy では、config ファイルの変換はビルド／パッケージングの時点ではなく、デプロイの際に行われます。
そのため、ベースとなる Web.config と、パッチである Web.Debug.config などは、一緒にパッケージに含めます。
App.config の変換は Visual Studio の標準機能としては用意されていませんでしたが、Octopus Deploy を使うと簡単に実現できるのも魅力です。
GitVersion との連携
OctoPack は GitVersion に対応しています。
GitVersion とは、Git のブランチ名などを元に、アプリケーションのバージョン番号を自動的に設定してくれるツールです。
Git-Flow と Semantic Versioning を使っているプロジェクトであれば、パッケージのバージョンは自動的に設定されます。
これを機に始めてみてもいいかもしれません。
本記事では GitVersion の使い方は割愛します。
.NET Core プロジェクトの場合
本記事執筆時点では残念ながら、.NET Core との互換性がありません。
.NET Core アプリケーションの場合は、後述する Octo CLI を使います。
パッケージ フィード
Octopus では NuGet と同様、アップロードされたパッケージの集合をフィードと呼びます。
ビルド時に、OctoPack が作成したパッケージを、このフィードにアップロードすることで、Octopus にアプリケーションの新しいバージョンを登録することができます。
Octopus のフィードには
- 組み込みの内部フィード
- 外部フィード
の２つがあります。
内部フィードとは Octopus Deploy 自体が持っているフィード機能です。
外部フィードとは、一般的な NuGet フィードです。そのため、例えば MyGet や Visual Studio Team Services の Package Management、あるいは自前の NuGet サーバーのフィード等を登録することができます。
内部フィードの場合しか使えない機能もあります。
一例を挙げると
- 自動リリース作成
- パッケージの保持ポリシー
などです。
それぞれの機能については、後で簡単に紹介します。
ビルド サーバーと Octopus Server が同じ社内環境にあるのであれば、内部フィードをお勧めします。
VSTS のような外部のビルド サービスを使う場合、内部フィードを使いたければ Octopus Server をインターネットに公開する必要が出てきますので、状況に応じて選択してください。
パッケージのアップロード
OctoPack にもビルド時にアップロードする機能がありますが、今回は Octo CLI を利用します。
ビルドが終わった後で、octo push コマンドを使って、フィードにパッケージをアップロードします。
API キーとサービス アカウント
Octopus の内部フィードにパッケージをアップロードするには、API キーが必要です。
これは、Octopus のユーザーに関連付けられます。
Web ポータルに対話的にログインする際のユーザー アカウントでもできますが、ビルド サーバーで CI をするような場合は、それ専用のユーザーを作ったほうがよいでしょう。
Octopus には自動化専用のサービス アカウントという機能があります。
通常のユーザーはユーザー名とパスワードで認証されますが、サービス アカウントは API キーのみで認証されます。
サービス アカウントの作成
新しいサービス アカウントは、トップ メニューの Configuration を選択し、Users → ADD USER で追加します。
Service Account にチェックをつけるとサービス アカウントになります。
アカウントができたら、NEW API KEY をクリックして API キーを作成します。
表示された API キーは忘れずに控えておきましょう。
ユーザーの権限
サービス アカウントには、いくつかの権限をつけてやる必要があります。
ユーザー アカウントに権限を設定するには、Team と Role を経由するという、少々面倒な手順が必要です。
Role の作成
まず、サービス アカウント用の Role を作りましょう。
Configuration の User Roles から、ADD CUSTOM ROLE を押します。
ここでは Service Account という Role を作成しました。
Permissions は、まずは BuiltInFeedPush をつけておきます。Octopus の内部フィードにパッケージを push するには、最低限、この権限が必要です。
Team の作成
続いて Team を作ります。Team はユーザーのグループのことです。
Configuration の Teams から、ADD TEAM を押します。
User Roles に先程追加した Role を、Members にサービス アカウントを追加して SAVE します。
これで権限をつけることができました。
Test Permissions で確認しましょう。
BuiltInFeedPush 権限が付与されていれば OK です。
その他の権限
Octo CLI でいろいろやるには、他にもつけておいたほうがいい権限があります。
ざっと挙げるとこんなところです。
- BuiltInFeedAdminister
- push 時に --replace-existing スイッチをつけて、既存の同じバージョンのパッケージを置き換える場合に必要です。
- FeedView
- ProcessView
- ProjectView
- ReleaseView
- ReleaseCreate
- create-release コマンドに必要です。
- DeploymentCreate
- DeploymentView
- TaskView
- deploy-release コマンドに必要です。
それぞれのコマンドについては今後紹介します。
試しに発行
ローカル マシンで Octo CLI を叩いてみましょう。
PS> .\Octo.exe push --package=WebApplication1.1.0.0.0.nupkg --server=http://octopus --apikey=<API Key>
エラーが出なければ完了です。
Web ポータルの Library > Packages にパッケージが表示されているでしょうか。
上手く行ったら、ビルド サーバー上で、ビルド完了時にこのコマンドを叩くように設定します。
おわりに
次回はアプリケーションのデプロイまで行きます。
あ、バージョン 2018.2 が出てました。
