TL;DR
- GitHubのReleaseと同等の機能はVSTSにはない(そもそも考え方が違う)
- VSTSのビルド成果物(artifacts)はリリースするためのものなので、保存は限定的であり、自動削除される
- 自動削除させないこともできるので、特定のバージョンのリリースをずっと保持しておくことで、GitHubのRelease相当になるが、見やすい一覧画面みたいなものはない
はじめに
という中村さんのツィートが発端です。これにこたえるには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に設定することでだいたい同じ感じになります。ただし、一覧で見るようなページはないので、それは拡張機能とかビルドタスクで作るしかないですかね。
