昨日まででCIができたので、今度はCD(Continuous Deployment)を紹介します。
はじめに
実はビルドとリリースのタスクは共通で使用できます。タスクを追加するダイアログボックスが表示されると、どちらにも同じものが出ています。なので、ビルド定義内でデプロイしてもいいし、リリース定義の中でビルドしても理屈上は問題ありません。
ビルドの中でデプロイするのも場合によってはありでしょう。自社以外のステークホルダーがいる場合、リリースの承認をもらうといったプロセスが必要になる場合があります。Release Managementはそんな機能を支援してくれます。
リリース定義の作成
ReleasesをクリックしてNew definitionからリリース定義を作成します。ビルド定義同様、作成数に上限はありません。実行時の並列数に応じて変わるのみです。
テンプレートからデプロイを選択します。Emptyを選べば一から作ることができますが、今回はAzure App Service Deploymentを選んでみます。
デプロイに使用するファイルの取得元です。Jenkinsやほかの場所からもとってこれます。今回は内蔵ビルド機能を使用したので、Buildを指定して、ビルド定義をしています。指定したビルド定義が生成したartifactsを取得してデプロイの元データとします。
なお、Jenkinsのような外部のWebサービスを使用する場合、チームプロジェクト内の歯車アイコンからServicesを選んでください。これはビルドのときも同じです。
赤字になっているところは入力必須項目です。もうSPNを使用したAzure Resource Managerデプロイが基本のようで、昔あった非Resource Managerは知らない子扱いのようです。
今回は組織アカウントを使っていますが、組織アカウントで試用アカウントを含むAzureサブスクリプションを管理しておけば、あとは選ぶだけですね。
というよりも、Azure側でApp Serviceを作っておけば、対象となるデプロイ先を選択するだけになります。
もしも組織アカウントに紐づていない(MSアカウントなど)アカウントで管理されているAzureへデプロイしようとなると、ビルド定義でAzure RMでのEndpointを作ることもできますがSPN作るのはめんどくさいです…。
Azureのサブスクリプションがない場合、ここで頑張ってください。
リリース実行
リリース定義を作りました！保存して、Saveをクリックすれば実際に始まります。
もちろんメニューからCreate Releaseを実行すれば開始されます。
artifactを選択します。artifactは1種類しかないので、primaryひとつですが、複数のartifactを指定することもできます。
このようなダイアログボックスから、ビルドとビルドが生成したartifactsを選択します。ここで選ぶのは一つだけですが、リリース定義では複数のartifactsを関連付けることができます。
リリースの作成ができたらRelease-1という文字列が表示されています。"Release-1"をクリックしてください。
ビルド完成です。ログや細かい解説はまた明日…
無事にデプロイも終了です。お疲れ様！
まとめ
簡単にCD機能をご紹介しましたいかがでしたでしょうか？Release Management機能を使えばビルドとほとんど同じUIでビルドのように簡単にリリース機能が作成できます。この手軽さを知ったら、自分でビルドして、ファイル作って…というのが非常に邪魔ですね。
メンテナンスやなれるまでに時間がかかると思いますが、使い続ければ非常にメリットのある機能なので、ぜひ使ってください。
