kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:ビルド/リリースで使う環境変数を見る(23日目)

はじめに

これはVisual Studio Team Services アドベントカレンダー23日目の記事です。

qiita.com

ビルド・リリースで実行するエージェントで参照できる値がいくつか定義されています。

docs.microsoft.com

ここに載ってはいますが、実際にどう定義されているのかという情報を眺めてみましょう。

方法

非常に簡単です。ビルド定義を作って、PowerShellで定義済み環境変数を列挙して表示すればいいだけです。

f:id:kkamegawa:20171223220901p:plain

こんな風にPowerShell Scriptのインラインタスクで[environment]::GetEnvironmentVariables()を実行するだけです。もちろん、ソースのpullが発生しないように、昨日同様、Don't sync sourceにチェックを入れてください。

f:id:kkamegawa:20171223220900p:plain

実行するとこんな感じです。スクロールすると、どんな値が定義されているか調べられるでしょう。

これを見て、実際にどんな値が定義されているか確認してみてください。

今日は簡単ですがこの辺で。

Visual Studio Team Services CI/CDアドベントカレンダー:PowerShellでビルド実行(8日目)

はじめに

これはPowerShellとVisual Studio Team Servicesの8日目のアドベントカレンダーです。

qiita.com

qiita.com

昔のVSTS/TFSでは.NETのオブジェクトベースのコマンドで管理していましたが、REST APIもだんだん実装されてきました。PowerShellでももちろん使えます。やってみましょう。

ちなみにコマンドもPythonベースのクロスプラットフォームのvsts-cliが提供され始めました。

docs.microsoft.com

ソース

Invoke VSTS Build definition by Build Name.

難しいことはほとんどありません。REST APIはこちらに載っています。現在はAPI version 2.0を使ってください。

www.visualstudio.com

注意点として、PAT(Personal Access Token)をつかってください。

docs.microsoft.com

上記のスクリプトを実行すると、指定したビルド定義名のビルドが実行されます。

f:id:kkamegawa:20171208230522p:plain

VSTSのREST APIでは名前では管理されておらず、IDで管理されています。名前はしばしば変わるから仕方ないですね。

なので、スクリプト中で登録済みのビルド定義の一覧を取得して、IDを逆引きしています。

機密性を上げる

ただ、これはスクリプトの中にPATを直接書いています。ローカルで使うだけのスクリプトであればまだしも、みんなが共通で使うものとしてはいけていません。

そこで、Azure Key VaultにPATを格納して、実行時はそちらを参照するようにしたいとします。

docs.microsoft.com

一応VSTSのvariableのシークレット指定をすれば2048ビットで暗号化されるとのことなので、お手軽にやるならこちらでもいいでしょう。一度シークレット登録すると、もう登録した人にも値は見えません。

f:id:kkamegawa:20171208230527p:plain

こんな感じでちょっと直します。

f:id:kkamegawa:20171208230526p:plain

空のビルド定義からPowerShell実行タスクを登録します。

f:id:kkamegawa:20171208230528p:plain

VariablesのVariable GroupからLink Variable Groupをクリックします。LibraryにあるVariablesのAddをクリック。

Key Vaultを作ったAzureサブスクリプションとKey Vaultの名前を選択します。

f:id:kkamegawa:20171208230523p:plain

使いたいVaultを選択します。

f:id:kkamegawa:20171208230524p:plain

Linkをクリックします。

f:id:kkamegawa:20171208230525p:plain

ビルド定義のVariablesにKeyVaultの値が関連付けられました。ビルドごとにKey Vaultを参照して秘密の値を取得します。

これでめでたしめでたし…ならいいのですが、実はまだちょっと動いていません。あとで直します。たぶん環境変数では参照できないんじゃないかと思っています。

さいごに

PowerShellのREST API久しぶりで色々忘れていました。特にJSON作るところとか、便利なんですが…最近はVS CodeのREST APIクライアント拡張機能があるので、エディタで書くだけでREST発行できて便利なんですよねw。

この辺の自動化でやりたいことがあるのですがそれはまた後日紹介します。

Release昨日のほうは紹介できませんでしたが、たぶんほぼ変わらないはずです。

VSTS/TFSの継続的インテグレーションとデータベース接続と単体テスト

データベース接続を動的に作る

最近、id:ishikawa-tatsuya さんのLambdicSQLというSQLをラムダでかいちゃおう、というOSSをid:odashinsukeさんと一緒にやってます。いろいろなデータベースに対応する(予定)ですが、とりあえず三人のスキルセットがそろっているSQL Serverを最初にやっています。

github.com

今までは個人でビルドしていましたが、CIやってみようかということで、個人的にVSTSのビルド定義を作ってみました。テストには当然SQL Serverを使うのですが、個人でやるときはそれぞれのSQL Server(LocalDBでもいいはずです)を使えばいいものの、CIとなるとちょっと困る。

接続情報はほかの人には教えたくないこともあり、LambdicSQLではProjectフォルダの下にdb.txtというファイルを作って、接続情報をそのまま平文で書いておくことになっています(もちろんgitignoreには定義済み)。

ではCIのときはどうするか?ということですが、こんな感じでやってます。

f:id:kkamegawa:20170510065239p:plain

まず、普通にVisual Studioのビルドテンプレートを作ります。次にPowerShellのタスクでインラインスクリプト(inline script)を追加します。new-item(別に要らないけど)とadd-contentコマンドレットで、db.txtにSQL Databaseへの接続情報を書いています。

f:id:kkamegawa:20170509055356p:plain

接続情報はそのまま隠すので、variableに独自で文字列を定義して、そのまま書いています。ほんとはタイムアウトとか変更できるように、サーバー名とユーザーID, パスワードだけ隠せばいいんですが。

テストを選別する

とはいえ、毎回すべてのテストが必要なわけでもありません。特にLambdicSQLにはデータベースをcreate/dropするテストもあります。SQL Databaseを作成するたびに2.33円(デフォルトのStandard S0の場合)かかるのはお財布にも優しくありません。

f:id:kkamegawa:20170509071834p:plain

そこでこんな風に、TestCategoryやPriority属性をつけておきます。

f:id:kkamegawa:20170509071833p:plain

テストエクスプローラーで「特徴」を選択するとこんな風にPriority1(CreateDrop以外)とPriority2(CreateDropDatabase)が区別できます。

f:id:kkamegawa:20170510064216p:plain

ビルドのTest AssembliesタスクのTest filter criteriaにPriority=1と指定すると、Priority属性が1のテストだけ実行されます。

Team Foundation Server 2017 Update1リリースと注意事項

TFS 2017 Update1

リリースされましたね。今回SQL Server 2016 SP1やWindows Server 2016もサポートされています。ハードウェア要件はこちらから。

www.visualstudio.com

Express Editionもリリースされていますが、前回同様機能差はなく、SQL Serverのライセンスが付属しない、フル機能が入っている(制限は人数のみ)のようです。6人以上使いたい場合はTFS CALになります。

リリースノートの注意事項

www.visualstudio.com

フィードバックしていますが、日本語版の翻訳には既知の問題が漏れていますので、英語版も見てください。

www.visualstudio.com

TFS 2013からのアップグレードを行うと"counter with name TaskReferenceId does not exist"というエラーが出ます。英文のリリースノートに回避するためのSQLが載っています。

そのほかの既知の問題も気を付けてください。

Erastic Search

TFS 2017 RTMからコード検索にErastic Searchを使うようになりました。RTMでは1.7でしたが、RTMでは2.4になっています。私の手元で何台か入れ替えたのですが、いずれもコード検索ができませんでした。対処としてはどちらかでしょうか。

  • アップグレードではなく、一度「TFS2017をアンインストール」してからTFS 2017 Update1をインストール
  • GitHubにある修正用のスクリプトを実行する

前者はデータベースさえあればいつでも戻るので、大丈夫です。後者はここにスクリプトがあります。TFS 2017用とTFS 2017 Update1用でフォルダが分かれているので気を付けてください。

github.com

Re-IndexingRepository.ps1というスクリプトを実行すれば治る…はずです。ちなみに私は全部やりました。

リリース前のスクリプトだとInvoke-Sqlcmdの -inputfile で指定するフルパスの解釈ができなかったので、pull request送って直してもらいました。

www.visualstudio.com

引数がちょっとわかりづらいですが、こうなります。チーム内にTFVC/Git両方ある場合、リポジトリ名はどちらを指定しても変わらないような気がします(一度の実行で全部直りました)が、チームプロジェクトごとにやったほうがいいでしょう。

  • SQL Server名(インスタンス名)
  • TFSのコレクションデータベース名(既定ではTfs_DefaultCollection)
  • TFSの構成データベース名(既定ではTFS_Configuration)
  • Git(Git_Repository)かTFVC(Tfs_Repository)か
  • コレクション名(既定ではDefaultCollection)
  • リポジトリ名(チームプロジェクト名)

これでしばらく待つと、再構築され、復旧するはずです。