kkamegawa's weblog

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

書籍レビュー:PowerShell実践ガイドブック

ちょうど読みたかったPowerShell実践ガイドブックのレビュワーをマイナビ出版さんが募集されていたので、応募したところ、見事当選しました。シェルに引っ掛けて貝殻が表紙になっているので、貝殻本だそうです。

貝殻本(と呼んで欲しいと書かれてた)とインサイドWindowsが同時に来た!

私のバックグラウンド

Windows PowerShellは1.0のころから注目していて、公私ともにぼちぼち使っていました。バッチファイルがどうも嫌だったんですね。単純に並べるだけならまだしも、制御文を考え出すとちょっとつかいたくないな、と。

ほんとうはC#がよかったけど、当時はC#スクリプティングもなかったし、似たような構文でかけるかも、ということでPowerShellという名前になったころからぼちぼち使い始めました。

第一章でPowerShellとどう付き合っていくか、という分類でいえば、「.NETのクラスライブラリを簡単に呼び出したい(&クラスライブラリの挙動確認をしたい)」あたりが近いでしょうか。

Linuxでbashでそこそこのシェルスクリプト書いてプロダクションとして使ったことがありますが、どうしてもなじめなかった。まさに書かれているように、=とかifの後などに空白入れちゃいけないなどの、ルール(?)になじめなかった。とはいえ、これはほかの人がWindows(PowerShell)に移ってきても同じだと思いますので、どっこいどっこいでしょう。

よかったところ

特に1,2章が圧巻でした。PowerShell Coreとは何なのか、また何故Windows PowerShellをメンテナンスフェーズにして、新しいPowerShell Coreを作ることにしたのかという事情やBash、コマンドプロンプトとの違い、検索TIPSやデバッグを丁寧に書かれていて、ここだけで本書の実に半分近くを占めています。

PowerShellなんて昔やったよ!という方が今のPowerShellを勉強しなおすために読み直すのもいいと思います。実際、私も忘れていたところや、あいまいな知識のままだったところ、PowerShell 4.0以降で追加された機能をもう一度参照できてとても勉強になりました。やっぱり本をまとめて読むのはいいですね。

わかっているけど、構文忘れたときはWebでの検索もいいのですが、全くゼロベースの知識から始めるときはこうやってちゃんと挙動や仕様を逐一まとめてくれた本はとても助かります。

また、検索のノウハウやデバッグの基本なども書かれているのは非常にいいと思いました。こういうの教えてもらわないといつまでも無駄な時間を使いますしね。特に「メッセージを英語で」検索するの重要です。本書でも書かれていますが、英語圏には圧倒的なリソースがあるので、解決に至るまでの時間も短くなります。

読み方

順序だてて書かれているので、読みやすくはあるのですが、それでもボリュームがある本なので、すでにWindows PowerShellを使いこなしている方であれば、1章を軽く見るだけで、2章,4章を読めばいいかなと思います。

これからPowerShellを始めるんだけど、という方はまず1章,2章でいいでしょう。少しずつ練習して、少し疑問が出てきたり、エラーをもっとちゃんと処理したい、よい書き方を学びたいという方は3章飛ばして、4章読んでから自分のスクリプトを改造するのもいいんではないでしょうか。

もっと書いてほしいところ

PowerShellといえばやはりMSによるスクリプティングのシステム管理を想定しているので、今はPowerShell CoreベースのDSC実装がないことによる運用がなかったのは(著者も書かれていましたが)もっと読みたいところでした。今後DSCの実装が出てきたときに改めて第二版や分冊といった形で出してもらえるといいかなと思います。

とはいえ、ないものをねだっても仕方ないので、今ならAnsibleなんかもあっても面白いかもしれないですね(ベータはあるのかな…)。

個人的にPowerShellに期待しているところといえば、REST使った外部WebAPIをたたくことによる自動化と、WinRM(これはWindows PowerShellですが)による複数マシンの制御なので、そういった本が別にあってもいいかなと思います。

MSが作っているのに、PowerShell Coreの活用はAWSのほうが先行しているという何とも皮肉な図ですが、AzureはWindows PowerShellようにリリースしているモジュールをそのうち合わせてくるのでしょうか。

ちょっと気になったところ

長いスクリプトは動かしてないので、その部分の正誤はわからないですが、少し気づいたところなど。次の版で直してもらえたらいいかなという程度で、本書の良さを損なっているわけではありません。

82ページ

コマンドプロンプト(MSDOS)
コマンドプロンプトはMSDOSではないですね。その後ではちゃんと「DOSではない」と書かれているので、あえてそう書かれているのかもしれませんが。あと、Windows PowerShellはメンテナンスフェーズと書かれているのに、エクスプローラにあるというのはちょっと説得力が弱いかなぁと思いました。

コマンドプロンプトのおそらく内蔵コマンドに関しては強化されることはないかもしれませんが、CUIを動かすシェルとしての強化はWSLと連携して続いていますしね。

132と136ページ

132ではSYNTAX(たぶんPowerShellの表示結果から)だが、136ページではシンタックスとカタカナ読みになっているのはわざと?

190ページ

void型を使うと、処理結果を戻り値のないことを表現できます
→少しへんな日本語

191ページ

「配列の節で説明しているので」
→ここに限らないのですが、後半では章レベルになるものの、参照が書かれているのですが、前に戻ってみるときに探さないといけないので、ちゃんと節番号で書いてもらえると助かります。

218ページ

リスト2-244に変数だけあって結果がない

222ページ、232ページ

「あえて一節を設けて」
→2.7なので、書くなら「一項」?

245ページのリスト2-292

PowerShellの実行結果ではなく、dotnet coreになってる。たぶんリスト2-291が間違い(実行できないソースのまま掲載)して、ずれてる。

268ページ

モジュールを任意の方法で読み込んだり、自動的な〜
→だりが一つしかない

322ページ

リスト3-69の前のところと文のつなぎがよくわからない

3.4の認証のところ

Windows PowerShellには証明書を使った認証もあるので、その言及があってもよかったかなぁ。

495ページ

初期値の説明がですます調(ほかはである調)

495ページその2

メソッドの説明の「記述できます、」の句点誤り

547ページ

5.1.6の内容は例外の再スローを避ける話なのに、タイトルがちょっと違う気がします。最初タイトルだけ見て内容とあわなくて?となったけど、ソース見て理解できました。

567ページ

Get-process のtypo

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

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のテストだけ実行されます。