GitHubのReleaseはVSTS/TFSにはないの？

TL;DR

• GitHubのReleaseと同等の機能はVSTSにはない(そもそも考え方が違う)
• VSTSのビルド成果物(artifacts)はリリースするためのものなので、保存は限定的であり、自動削除される
• 自動削除させないこともできるので、特定のバージョンのリリースをずっと保持しておくことで、GitHubのRelease相当になるが、見やすい一覧画面みたいなものはない

はじめに

プロジェクトで使う、でっかいサードパーティライブラリの保管場所みたいのって、VSTSにはないのかな？
あと、GithubのReleaseタブみたいにファイル添付できるとこ

— Atsushi Nakamura (@nuits_jp) 2018年7月31日

という中村さんのツィートが発端です。これにこたえるには140文字では短すぎるので、回答をまとめるアンサーブログです。

GitHubのRelease

About Releases - User Documentation

ご存知の方も多いと思いますが、GitHubのReleaseとは、GitHubレポジトリに公開されているソースをほかのCIサービス(AppVeyor, CircleCI, Herokuなどなど)でビルドした結果のうち、所定のバージョンを公開するためのものです。

通常はこのReleaseからダウンロードして、所定の環境に展開します。例えば、JenkinsやAnsibleなどでダウンロード＆インストールという方法が考えられます。Releaseに登録されるファイルにはバイナリ、タグ、コミットハッシュなどがついていて、関連情報があさりやすくて大変便利です。

なお、現時点において、GitHubのReleaseに登録したファイルはAWS S3に配置されているので、企業のアクセスポリシーでAWS S3へのアクセスを許可していないと、Releaseから取得できないので、気をつけてください。ただし、VSTS Build AgentのようにReleaseのダウンロード先にカスタムドメインを指定しているものもあります。おかげでS3アクセスできない環境でもとってこれて助かりました…。

VSTSとTFSのRelease

VSTS(TFS)にもReleaseという機能はありますが、こちらはちょっと違います。VSTSのReleaseは「成果物(artifacts)を指定の環境(VM, PaaS)へ展開する」機能です。

Understand how Microsoft Release Management works | Microsoft Docs

成果物はVSTSのBuild機能で生成することが一般的ですが、Build機能を使わなくてもかまいません。VSTSのReleaseの入力にはビルド結果以外にもこれだけサポートしています。

• 静的WebサイトであればVSTSのGitから直接展開する
• Jenkinsのビルド結果を使用する
• Docker Hub/Azure Container Registoryからコンテナーを展開する
• GitHub / 外部のGitから展開する

GitHubのReleaseと名前は同じですが、機能的にはJenkinsに近いです。JenkinsではBuildもReleaseも明確に区別されていませんが、VSTSではそれぞれ別の責務です。

とはいえ、どちらもほぼ同じタスクが使えるので、VSTSのBuild機能でもデプロイできますし、Release機能でもビルドができます。小規模な環境であったり、最初のテスト的に行う場合であれば、Buildでリリースを行っても構いませんが、将来的にはReleaseと併用することをお勧めします。逆にReleaseでビルドするのは全くお勧めできません。

分割する理由として、CI成功即デプロイとすると、CIが重くなりすぎ、リリース時にいわゆるシステムテストして、問題ないかどうか確認したいというのが理由になるので、避けるべきです。

ビルド結果をVSTSに保存する

VSTSでビルドしただけではビルド実行後サーバーから削除されます。それでは困るので、Publish articlesビルドタスクでVSTS、もしくはファイルサーバー内に保存します。

通常はVSTS内に保存で構いません。これを使わないと、後述のRelease機能でビルド結果を使うことができないので、気を付けてください。

VSTSでの成果物自動削除

VSTSはビルド定義やコードレポジトリ容量などいろいろ容量無制限をうたっていますが、ビルド結果は少し制限されています。

VSTSのビルド結果の保存条件のデフォルトはRetention Policyで初期値が決まっています。

• 直近成功したビルド結果はビルド定義を削除するまで保持される
• 二つ以上のビルド結果はRetentionの定義に従って、自動削除される
• Gitの場合、masterブランチは10回分残す、devブランチは1回のみ残すという柔軟な構成が可能

そして、これらRetain PolicyはBuild/Release個別にProject Adminメニューから設定できます。VSTSはSaaSサービスという都合上、このような上限が決まっていますが、オンプレミスのTFSの場合、SQL Serverのディスク容量のみに制限されるため、上限はありません。

Build 結果保持

Retain Policy初期値

BuildはRetaintion and Limitsで初期値がわかります。

• 最大30日、最小10日
• 最小1ビルド結果保持、最高10ビルド結果保持
• ビルド時の記録の削除：する

ビルド結果を保持する

とはいっても、特定のビルドを保持しておきたいことはあります。ビルド結果からRetainを選択します。これでビルド結果毎に個別に保存されます。

ビルド定義単位で指定する

ビルド結果毎にいちいち指定するのは面倒です。特にmasterブランチやリリースブランチは必ず保存したいと言う場合、ビルド定義の三点リーダーをクリックして、Retain Indefinitelyを選択すると、そのビルド定義の結果は常時保存されるようになります。

クリックすると、Stop retaining Indefinitelyになっているので、もう一度クリックすると、通常のポリシーになります。

ブランチ単位の保持(Git)

Gitの場合、ブランチごとに保持期間を設定できます。

• masterは長く残したい
• Devブランチ配下は少し長く残したい
• それ以外のブランチはすぐ消してもいい

こんな場合に使えます。

初期状態では最長10日、直近1成功ビルドのみ保存です。最低1ビルドなので、10日以上経過しても直近1成功ビルドが消されることはありません。

masterだけ直近5成功ビルドのみ残すには+ Addからポリシーを追加します。この設定で直近5成功ビルドが最大10日間残されます。ポリシーは上から下に評価されるので、うえのポリシーに何も一致しない場合は最後の「直近30日、10成功ビルドを残す」が評価されます。

Release 結果保持

BuildとReleaseの責務が分散されているように、Retain Policyも別設定になっています。

Retain Policy初期値

Buildと同様にReleaseの全体的なポリシーです。

• 最大365日、最小30日
• 最大25リリース、最小3リリース
• ビルドを保持する
• リリース14日後削除

リリース定義のRetain Policy

Build同様に、Releaseにも定義毎にRetain Policyの設定ができます。

Retentionハブから設定します。Days to retain a releaseで保持しておく日数、minimum release to keepで最小保持リリース数を指定します。

リリース結果のRetain Policy

Build毎と同様、ReleaseにもRetain Policyが設定できます。

リリースの三点リーダからRetain Indefinitelyをクリックしてください。Buildと同様に無期限保持になります。

GitHubのReleaseに近い機能

サードパーティーのライブラリ置き場に近い機能はないの？ということであえて言ってみれば、近い機能はPackage Management機能ですね。ただし、こちらは有償の機能で、VS Subscription Enterpriseを持っている人はサブスクリプションに含まれます。

どんなことをする機能かといえば、組織内Nuget/maven/npmのサーバーを独自に用意できるというものです。オリジナルのサーバーをupstreamに指定することも可能なので、プロジェクトのスプリント期間中はユーザーに勝手にアップデートしてほしくない、という場合非常に便利です。

もちろん、自前の外部に公開したくないパッケージを保存しておく場所としても有効です。

まとめ

VSTSおよび、TFSにはGitHubのReleaseと全く同等の機能はないですが、masterブランチのビルド結果をRetain Indefinitelyに設定することでだいたい同じ感じになります。ただし、一覧で見るようなページはないので、それは拡張機能とかビルドタスクで作るしかないですかね。