kkamegawa's weblog

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

VSTSのビルドタスクで使用するAppleの証明書を切り替えたい

こんな質問を見かけたので、考えてみました。実はコメントでdownload secure fileタスク使って必要なファイルをダウンロードするしかないのかなぁ、と書いたのですが、conditional taskを使えばもっときれいにできることを思いついてしまいました。

conditional taskについては以前書いたので、こちらを見てください。

kkamegawa.hatenablog.jp

やり方はそう複雑ではなく、Install Apple certificationタスクを二つ登録して、それぞれのCustom conditionにVariableの値を評価するというやり方です。こんな感じ。

f:id:kkamegawa:20180606063242p:plain

VariableのApplecertificateに"production"と書かれていたときだけ実行する。

f:id:kkamegawa:20180606063240p:plain

VariableのApplecertificateに"demo"と書かれていたときだけ実行する。

f:id:kkamegawa:20180606063241p:plain

Variablesに"Applecertificate"を登録して、右端のSettable at queue timeにチェックを入れます。このチェックがあると、手動実行時にVariableの値を任意で指定できます。ここでは空欄にしていますが、デフォルトの値を決めておけばCIで回すときには指定した値が使われます。

あるいはREST APIを使って、ビルド指定してもいいかもしれません。

docs.microsoft.com

これでビルド実行時Applecertificateの値に一致するほうの証明書をインストールします(証明書持ってないので、ここから先は画面がありません)。

Visual Studio Team Services 2018/5/30の更新

Visual Studio Team Servicesのリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

今回の目玉としてはリリース進行状況がかなりグラフィカルでリッチな見栄えになっていることですね。ちょっと前から使っていますが、見栄えはいいです。問題点としてはリリースゲートでエラーが出たときのログが旧ビューでしか見えない点でしょうか。フィードバックされているので、そのうち直ると思います。

pull requestのポリシーの上書きはサービスを運営している場合や、承認者が上司で不在がちとなっている場合にしばしば発生するでしょう。お互い信頼しているような組織では非常に便利だと思います。

プライベートエージェントの並列度のライセンスが緩和されたので、注意事項にあるように、並列処理ビルドのキュー待ちにならないようにプライベートエージェントを使っている場合は気を付けてください。Account Setting → Build and Release → Resource limitsで確認できます。

ではまた三週間後。

Translate to Japanese to VSTS release notes from h ...

書籍レビュー: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をAzure ADベースで使いたい

Visual Studio Team Services(以下VSTS)には二種類の認証方法があります。MSアカウントとAzure ADです。MSアカウントは原則個人向け、Azure ADは会社などで使う場合に向いています。

どちらを選んでもVSTS自身の機能差はありませんが、Azure ADを選ぶと、Office 365との連携が便利になる場合が多いです。例えば、Teamsとの統合やAzure ADのグループをそのままVSTSのグループとして扱える、という点ですね。

Azure AD側で「xxPJ開発チーム」というグループを作って、VSTSのチームプロジェクトにできると管理が一元化されて便利です。

さて、そんなAzure ADですが、Office 365の認証基盤でもあるため、先にOffice 365を導入しているところも多いと思います。そうなると、VSTSもOffice 365のAzure ADで認証させたい、と思う方も多いと思います。

しかし、たいていの大きな会社ではOffice 365を管理している部門と、開発者は別というか、非常に遠い。そして、VSTSなんか入れてなんかあったら困る、という問題もあります。

f:id:kkamegawa:20180525063818p:plain

特にこんな風に外部のパートナーさんに追加してほしい場合、Office 365のライセンスを発行するというのは費用面やアカウント管理としても面倒です。Office 365を使っていないとしても、Azure ADのP1やP2であればユーザーごとに結構な費用がかかります。

私も困っていたのですが、そんな時はこうすればいいんじゃないか、という話を教えてもらいました。

f:id:kkamegawa:20180525063819p:plain

  1. 新規にAzure ADを用意する。Azure ADそのものは無償で作れます。
  2. そのAzure ADのテナントにVSTSを作る(まだ無償)
  3. Azure AD B2Bで新規に作ったVSTS用Azure ADに参加する。
  4. パートナーさんがいる場合も、パートナーさんのAzure ADのユーザーをB2Bで追加する。

重要なのは必ずB2Bで参加するという点で、VSTS用のAzure ADでユーザーを作らないということです。仮に作ってしまうと、パートナーさんが自分たちのAzure ADを作った、もしくは持っている場合、パートナーさんのユーザー管理や認証がややこしくなります。

Azure AD B2Bを使うとき、セキュリティ的な問題で多要素認証を使いたい場合、有料のBASIC, P1, P2が必要になります。しかし、そんなときでもあくまでもVSTS用のAzure ADサブスクリプションにかかるので、所属会社への費用は発生せず、お金的にも分離が可能ですね。

azure.microsoft.com

Team Foundation Serverの時代にWorkgroupでサーバーのユーザーで管理していた癖で、VSTS用のAzure ADにユーザーを登録したくなるかもしれませんが、絶対にやめたほうがいいでしょう。

仮にこれがSIの受託開発だった場合も大して変わりません。最終的にAzure ADおよび、VSTSの所有者をお客さんに変更すればそれが納品物、もしくは環境の移管ということになります。実際にそういうことをやられている方もいるようです。