kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

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

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、もしくはファイルサーバー内に保存します。

f:id:kkamegawa:20180805084928p:plain

通常は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で初期値がわかります。

f:id:kkamegawa:20180805084935p:plain

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

ビルド結果を保持する

f:id:kkamegawa:20180805084936p:plain

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

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

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

f:id:kkamegawa:20180805084932p:plain

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

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

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

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

こんな場合に使えます。

f:id:kkamegawa:20180805084933p:plain

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

f:id:kkamegawa:20180805084934p:plain

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

Release 結果保持

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

Retain Policy初期値

f:id:kkamegawa:20180805084931p:plain

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

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

リリース定義のRetain Policy

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

f:id:kkamegawa:20180805084930p:plain

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

リリース結果のRetain Policy

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

f:id:kkamegawa:20180806220947p:plain

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

GitHubのReleaseに近い機能

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

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

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

まとめ

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