kkamegawa's weblog

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

Office 365 Groups Connectorを使ってVSTSと連携する

Office 365 Connector

Office 365のグループ機能には少し前からOffice 365 Group Connectorといって、外部のサービスからグループに投稿することができるようになりました。

dev.outlook.com

リリース当初は用意されていなかったのですが、いつの間にかVisual Studio Team Servicesとも連携できるようになっていました。ちょっとやってみましょう。

注意点

この作業はVSTSのService Hookの欄にもあり、一見VSTS側からもできるように見えますが、必ずOffice 365側から承認する必要があります。

f:id:kkamegawa:20160530060313p:plain

作り方

最初に事前にグループを作っておいてください。作ったら必要な人を招待しておきます。

f:id:kkamegawa:20160530055502p:plain

ConnectorからVisual Studio Team Servicesを選択して、追加します。

f:id:kkamegawa:20160530055503p:plain

アプリケーションを承認します。

f:id:kkamegawa:20160530055504p:plain

コネクタに使用するVSTSアカウント、テナント名、プロジェクト、EventType(ちなみに後で複数構成できます)、Work Itemの種類やイテレーションパスなどを選択できます。

f:id:kkamegawa:20160530055505p:plain

コネクタが構成されました。今回はWork Itemの追加のみにしましたが、不足していればAddボタンで任意に追加することが可能です。

f:id:kkamegawa:20160530055501p:plain

VSTS側で追加するとグループに投稿されました。

f:id:kkamegawa:20160530055506p:plain

同様にOutlookでも受けることが可能です。

まとめ

簡単にグループあての通知を作ることができました。

実はVSTSでもタスク変更やpull requestが発生したときにAlertメールを飛ばすことができるのですが、VSTS側のGUIで操作しないといけないということがちょっと面倒でした。Office 365 Group ConnectorならGraph APIを使って外部から一元管理することができます。

極端なことを言えばVSTSアカウントがない人を追加しておくと、進捗状況を見せたり、グループに投稿されたスレッドを別のアプリから吸い上げることでVSTSにアクセスすることなく、タスクボードを別途作りこんで、外部に公開するむことだってできそうです。

graph.microsoft.io

Microsoft Graph - ドキュメント - メンバーを追加する

Microsoft Graph - ドキュメント - スレッドを一覧表示する

de:code 2016 Day 2

昨日に引き続きde:code 2016 day2です。昨日の記事はたくさんの方に読んでいただいたようで、ありがとうございます。

Windows 10の展開

Windows 10のアップグレード無償期間がもうすぐ終わります。改めてWindows 10を展開するときの方法について。

  • インプレースアップグレード
  • プロビジョニング(新規展開)
  • ワイプ&ロード

今回は主にワイプ&ロードをご紹介。セッション担当はSamir Hammoudiさん。組織内で展開するにはワイプ&ロードが90%。残りがアップグレードとプロビジョニング。エディションはEnterprise 33%,LTSB 22%。残りがPro。結構意外な割合ですね。

家庭ではほとんどインプレースアップグレードだと思いますが、組織では不要なインストール済みファイルを消したい、アップグレード信用できないってのがそうですね。あと、今だと暗号化ソフト(BitLockerはインプレース対応しています)があるため、なかなかできない。

しかし、サードパーティーの暗号化ソフトでもアップグレード用のフィルタドライバをパッケージに追加しておけばいいんだそうだ。海外の著名なベンダー(Symantec,Mcafeeなど)は対応している。ドメスティックなやつは聞いたことないし作る気もないんかな。人を楽にするための工数なんか知ったことかという感じなんだろう。儲かるネタでもないし。この辺はDevOpsの話を聞いてもそうだけど、本当に考え方が違う。

ほかにもインプレースアップグレードできないパターンは知っている人も多いと思うけど、x86→x64とか、表示言語違い、BIOS→UEFIにする、デュアルブートとかの日本ではそうでもないけど、はまる人ははまりそうなパターンや、実際にワイプ&ロードするためのツールの紹介など、知っていたけど、ちゃんとまとめて教えてくれると今度やらざるを得ないときとかはネタになりそうです。

基本的な移行ならWindows ADKやMDT 2003といった無償ツールで可能だけど、知られていない。さらにはドキュメントやツールそのものが分かりにくいという点もあるのは難しい。Igniteとかではこの辺ちゃんとセッションやハンズオンがあるんだろうけど。

プロビジョニングに最適なシナリオとしては外出先のデバイス紛失時の復旧。VPN、Office、ドメイン参加、証明書といった情報を入れたイメージをクラウドサービスにおいておけばOK。セッション担当者もアフリカの砂漠のなかでUSBドライブ使ってプロビジョニングされたイメージを展開するというプロジェクトやっていたこともあって、非常に説得力ありました。

拝啓「変わらない開発現場」を嘆く皆様へ

事前に資料が出ていたので、非常に期待していたセッションの一つです。いわゆるエンタープライズ向けSI企業の開発にはぐさぐさささるだろうセッションでした。

de:codeではいろいろ新技術が語られますが、「今」現場で困っていることを解決するヒントみたいなものを与えてくれるセッションでした。テストの自動化もそうだし、開発の軽量化もそう。高速開発みたいな与太じゃないけど、個人的にはうーんと思うものもあるけど、根本は世界が変わっているんだからやり方も変えないといけない。単なる従来の延長で早くしよう早くしようと思っても無理。

欧米の人は非本質的なことを徹底的に排除するのが非常にうまい。牛尾さんのdevOpsセッション出ると、じゃあ「西洋文化をインストールしましょう」という話もあったんだけど、ここでは少し異なるスタンスでいいところをもらって融合させようと。

特に戦後日本人の気質がIT開発においては悪いほうにしか向かってないので、そこをなんとか軽量化していく。軽量化とは後戻りさせない、パートナーが作ったものをもう一度検査するようなことはしない。

設計書もコードが見えるような設計書じゃないとオフショアとかパートナーが書けないから書いちゃうというのは無駄。改善しようという話だったけど、そこを改善していくには低いレベルのままじゃダメで、まず開発者としての基礎体力(C#ちからでもVB力でもJava力でもなんでもいいんだけど)していかないといけないかなと。

発注側もそういうところを切っていくというかできるようにしていかないといけないけど、会社で契約した場合、だれが来ても「チェンジ」とかできないのは難しい。さらには契約によってはその人に教育を行うとかもできないしね。

PMもカンと度胸はだめ。すべて技術。基礎理論の前に背景を学べばそこに気づきができる。このツールがこういう思想になっている背景は何があるかということを無視してしまいがちですね。PMは作れる必要はないんだけど、今どきの開発手法とか知っておいてテストや設計にも技術があることを理解しておこうと。実際やっている人、どれくらいいるんだろう。ニュースサイトすら見ないという人も多そうだ。

最後

企業アプリケーションアーキテクチャのトレンドをつかめ

安定の森屋さん。基本的にはASP.NETで今どきのクラウドサービスを一気通貫でつなげで、クラウドサービスのみで本番までデプロイ、さらにはチーム開発の勘所みたいな話も行われました。

確かに「Dockerが流行っている」とは聞いてDocker個別の話はあちこちであるけど、一気通貫でみせないとピンとこない人にはこれが開発をどう変えるものなのか、ということが分かりにくいから、ちゃんとつながった状態で見せましょう、という話はそうだよなと。

ちなみにGitHub→DockerHub→CircleCI→Docker cloud→Azure/AWSへ同時デプロイなんて流れでデモを見せてくれました。今どきですね。

Xamarin.Forms Deep Dive

会社でXamarinを売れなくなったけど、コミュニティエヴァんじぇリストとして頑張っておられる田淵さん。Formsの基礎と、Alphaチャネルにしかないリアルタイムプレビューと、初めて見た人はくじけてしまいそうな(Alphaだし)不安定ぶりを見せつつ、Formsが業務でどんな感じで使えるのかというエッセンスをうまく説明してくれていたと思います。

今回はさらにEvolveで発表された動く仕様書(ドキュメントページに書いたコード片がそのままうごく)Workbooks,サーバサイドでJSONを作ればクライアントサイドでいい感じにバインディングしてくれて何も書かなくても画面ができちゃうDataPagesとかは初見ではびっくりしますよね。

DataPages - Xamarin

Xamarin Workbooks - Xamarin

この辺は発想と実装力に脱帽です。

エンプラ系Webアプリ開発に効く!実践的モダンWebアプリ開発の選択手法

JavaScriptライブラリの変遷ってホント早いですよね。今選んでも3年後にあるかどうかわからない。prototype.jsだって10年ほどしかたってないのに、影も形もないと言ったら失礼だけど、話題に全く上らない。

そんなOSS系を「今あるから」といって採用するのは確かにリスキー。そういうのを防ぐためには商用のサポートのある製品を買っておけばその範囲で面倒見てくれるのは正しい選択。

流行りのツール(gulp,TypeScript)なんかも別にすぐに使わなくてもいい、その前にまずは最初(ここではWeb開発初心者を前提にしている)がどうやって無理なく、今のWeb開発技術をうまく取り込み、さらには時流のツールを使えるようにするのか、という点で地に足がついた提案がいろいろ行われていました。

完全にクライアントサイドのJavaScriptだけで完結するのではなく、適宜サーバサイドもうまく使っていくのはVisual Studioの一貫した支援が受けられるツールセットならではですし、慣れた環境がそのまま使えるのも大きいので現実的。

もちろんJavascriptとASP.NET MVCで検証ロジックなどを二重開発しなくて済むようにもできるしね。

Web開発初心はHTML(5固有の機能ではなく)の開発で参照系の開発からやってみて、jQuery,Bootstrapだけを使ったアプリ作ってみて、徐々に新しいツールでステップアップしていこうというのは確かにそうだなと思います。私も何やっていいのかわからなくなることあるしw。

まとめ

今日はアーキテクチャと現実wの話を中心に聞いてみました。エッジなセッションは人気も高くてねぇ…いくつかみてみたい動画はあるので、なんとか見てみようかなと思います。

権利関係や大人の事情とかで公開されないセッションが少なくなりますように。

de:code Day 1

キーノート

pc.watch.impress.co.jp

いくつかメディアですでに出ているので、書いてもなんだという感じもありますが。キーノートは立ち見&サテライト会場に行くくらい参加者がいたようで盛況でした。今回は前夜祭が開催され、前夜祭ではついでにレジストもできるという特典もありました。当日かなり並ばなくてもいいのは大変助かりました。とはいえ、翌日から参加の友人と一緒に並んでいたのですがw。

キーノートはCEOのSatya Nadellaも登場し、本国のイベント同様にかなりの時間しゃべってくれたのは驚きました。報道によると、そのあとすぐに別イベントをこなされていたそうで。今日からAPAC Tourということで各地を回るんですね。

Keynote at Singapore Microsoft Developer Day

ノリは本当に//Buildのキーノートのようで、最初からchannel9の中継ブースでいつもおなじみのSeth氏が日本の英ぺ三人衆と軽妙にしゃべっているなーと思ったら、いつの間にか井上 章さんいなくなっているなーと思ったらブリジストンのつなぎきてコスプレw(コスプレ担当と自虐…)。アプリはXamarin制で音声コントロールで入力できるのは確かにああいうニーズに合ってそうですね。現場はうるさくても大丈夫なのかな?

Desktop App Convertorもお披露目されましたが、まさか秀丸持ってくるとは。しかし、いいチョイスです。誰もが知っている日本のアプリで、さらにシェアウェアということでわかりやすい。ものの1分かそこらでコンバートされていました。しかし、注意点として、UWPアプリではない、んですよね。あくまでも「ガワ」がUWPになるだけで、ライフサイクルとかは普通のWin32アプリケーションです。もちろんこんてぃにゅーむとかにも対応しないので、Windows Mobileでは動きません。私の知り合い(開発者ではないがモバイルオタク)でも勘違いしている人がいました。

最後は牛尾さんの上司のクレジットカードに物を言わせて、Chef, Mesosphere, Jenkinsを使った1000コンテナへのデプロイ。最後にはMicrosoft Loves OSS ロゴ。地味だけどそれをカバーする牛尾さんのダンスとテンションの高さに会場は一部以外置いてけぼりw。

最後はいつものキーノートイメージビデオでしたが、ちょっとそこそこにしてランチセッションに行きました。キーノートとてもよかったですが、映像によって中央のスクリーンと複数にミラーされているのと両方あってどこを見ればいいのか少し迷いました。

Windows 10開発の舞台裏から学ぶエンジニアの未来

DevOpsトークセッションが満席だったので、こっちに移動。「顔が見えるMSD(Microsoft Developmentという別会社)」をテーマにWindows 10開発の舞台裏をいろいろ話してくれて興味深かったです。

  • 開発者は多ければ10-20のVMを使い、基本的にデータセンターもしくはローカルのサーバで仮想環境を運用。つまり場所にとらわれず、安全な開発。使っているものもみんなが使っているWindows 10に含まれるインフラ。
  • 数千人の開発者が8時間みっちりやって、出るかどうかというバグでも数百万のInsiderに提供すると30秒かそこらで発見される。思ってもみない使い方をする人も多い。
  • 2006年Windows as a Serviceはまだジョークで、言い出した途端会場爆笑。言い出しっぺともう一人の二人でブレスト始めたところBillGが乱入(ってすごいな)。
  • Cortanaの前のパーソナルアシスタントといえばOfficeのカイル君をはじめとするAgent。ただし、全世界で不評だったが、唯一受けたのが日本のみで冴子先生w。
  • Cortanaのイントネーションの進化。合成音声から声優さん(Haloと同じ)に切り替えている。しかもHaloは戦闘中のアシスタントということで、演技を変えてもらっているというところがプロ。
  • 日本語の「コルタナさん」はすべての状況で問題なく起動するように。日本では"Hey Cortana"はテンション高く、一人じゃないと難しい(確かにねー)。「さん」がついているのは名詞としての「Cortana」できどうしないようにというルール。

あたりがとても印象に残り、すごく興味深いセッションでした。

Microsoftが実践したScrum導入7年の旅とDevOpsへの進化

MSのVSTS/TFSチームが実際にスクラムを導入して、DevOpsへ至るまで7年間かかった道のりを解説。牛尾さんのこの資料のオリジナルを作った方の解説です。

  • 本番以上の学びの場所はない
  • スプリントは3週間だが、半年ごとにSeasonという単位で将来の開発方針を見直し、同じことをやっているチームがあればスプリントを一緒にするということもある
  • Sprintは担当するチームが決まっていて、担当者一覧が入るメールが通知
  • できたこともメールで通知。動画が含まれるが「何をやった」ではなく、「以前とこう変わった」という動画。ChatOpsみたいなのではないのね。この辺はOffice 365をもっていて、Office Graphとかで分析できるMSならではなんでしょうか。
  • 普通のサービス会社はサービスのことだけ考えていればいいけど、オンプレミスのTFSもあるので、サービス更新の戦略がちょっと違う
  • 以前はリリース前にすべてのシナリオをテストするビッグテストだったが、それでは三週間ごとのリリースには間に合わないので、トピックごとに影響するような細かいテストに改めている。
  • フィードバックをいろんなチャンネルで得るが、自分の予想通り、予想に反する、どうでもいいがきれいに33%ずつ。
  • 攻撃を受けている、という前提ではなく「すでに誰かが入っている」という前提で実施するセキュリティの演習

とても興味深い話ばかりでした。社内にも展開して、オンプレミスのソフトもリリースし、そのうえでいろいろ改めるというのはどこの会社でもできるかどうかわからないけど、テストのやり方、リリースに関しては参考になります。

カンバンによるアジャイルプロジェクトマネージメント本が先行販売されていたので、購入。

Azure/Windows Server 2016から学ぶWindows系インフラエンジニアのためのDevOps

小塚&高添コンビのインフラよりのDevOps話。小塚さんと牛尾さんの仲がいいんだか悪いんだかというDevとOps一体となってやりましょうを最初から否定するかのようなアイスブレイクから。

  • ビジネスチームとOpsチームとDevチームがある。よく語られるのはビジネス→Devだがビジネス→Opsもあるよね。
  • Opsが情報をサマライズするのではスピードが足りないので、セルフBIでビジネスチームが自分で見えるように整備
  • Opsチームは減点法。何かあると怒られるので、デプロイをリスクにしない。低リスク、高バリューを得るためにIT投資
  • Windows Server 2016はそのための機能をたくさん用意しているが、好きなものを使ってください。
  • Windowsコンテナを使う場合もまずはDockerのコマンドを覚えて、足りなければPowerShellで
  • コンテナはデプロイしたらすぐ動く状態。「デプロイしてこれやって」はNG

本当にWindowsでDevOpsやるためのインフラには何があるか、Windows Serverはどうよくなったのかという概要セッションでした。細かい話は別の個別セッションでしょうね。

日本でもできる!マイクロソフト技術をフル活用したDevOpsの具体的開発手法

再度テンション高い牛尾さん。しかしいきなりネットワークが不通でスタッフコールw。よく「海外の方法そのままじゃダメ、日本流にアレンジしましょう」みたいなことをいろんなところがやりたがるけど、それではだめ。薄いカルピスのようになってしまうという話がとても印象的でした。ギャップがあるなら改良するのではなく、そのまま西洋文化を挿入すればいいという考え。

この辺は牛尾さんのブログでたくさん書かれているので、ぜひ読みましょう(手抜き)。

simplearchitect.hatenablog.com

NECソリューションイノベータの事例でVSTSを使ったデプロイで8.5か月かかっていたデプロイまでの時間を一週間(!)に短縮した事例。具体的には明かされなかったけど、1990年代の開発から2016年の開発になったという声があるそうで。そうだよねーExcelと32bitマシンと手でのデプロイ、とかからいきなりコンテナとかよくついて行けたなと。

でも、承認者が許可すれば今まで無駄だったことがすべて破棄できるので、必ず意思決定者を巻き込みましょう。あきらめているとそこで試合終了ですよ、みたいな話が印象的でした。VSTSを使ってでもしていたけど、まぁその辺はどうでもいい。

まとめ

実は始まる前からびっくりしていたことがありました。まず、スポンサーにNEC,富士通,日立,NTT Data, CTCさんといった従来割とスポンサードされていた企業が全くなかったんですね。代わりに「MSのサービスを使っている」「連携する」企業群。ちなみに同じ日程でJavaOne Tokyoやっていて、そちらにスポンサーがあったそうです。全部が全部日程かぶりでスポンサーしないってのはちょっと考えにくかったので、方針もあったのかなぁという感じです。

Sponsor - de:code 2016 | 日本マイクロソフトの開発者/アーキテクト/IT Pro 向けイベント - Microsoft Events & Seminars

de:codeは開発者向けのイベントといいつつ、この辺伝統的な企業向けのイベントかなぁとも思っていたのですが、キーノートとスポンサー一覧見て、一周戻って「MSの製品を使って何か作ってくれる」開発者向けのイベントになったんだなぁ、と改めて認識しました。

パーティは相変わらずの激混み。この辺はExpo会場もつぶさないとどうしようもないでしょうけど…あとは通路。

ジニアスのセッションに入れなかったのは痛恨の極み。DevOpsトークバトルとジニアスは満員御礼でダメでした。ほかは大体キャパシティプランニングうまくいっていたと思います。小部屋多くしていたのはよかったのか悪かったのか。

channel9ステージは後ろからってことで、ちょっとよく見えなかった。この辺はオンラインの人向けのサービスだったんでしょうかね。

VSTS/TFSでC++アプリケーションのビルド用テンプレートを変更する

はじめに

VSTSでビルドを行うとき、いくつかのプロジェクトタイプではビルドテンプレートが用意されています。新規作成するときにVisual Studioというテンプレートがあるのですが、これは.NETプロジェクト用になっていて、いくつかのビルドステップに不都合があります。

インデックス作成シンボルの発行

検索パターンがオリジナルでは「**\bin\**\*.pdb」となっています。しかし、C++プロジェクトのデフォルトテンプレートではx64\Releaseという形になるので、これではシンボルが発行されません。
余談ですが、このインデックス作成は.NET用の機能のようで、ネイティブのpdbでは警告が出ます。 そこで検索パターンを「**\$(BuildPlatform)\$(BuildConfiguration)\*.pdb」という感じにしましょう。

f:id:kkamegawa:20160520064149p:plain

ファイルのコピー先

これも同じです。検索パターンが 「**\bin\$(BuildConfiguration)\**」となっているので、これでは都合が悪いので、変更します。
コンテンツはexeとdllだけにしていますが、別の拡張子があれば|で追加してください。ソースフォルダーを変更しているのは私の場合一つだけビルドしたかったからです。複数の構成を一度にビルドする場合、$(build.sourcesdirectory)をルートにして、コンテンツに\$(BuildPlatform)\$(BuildConfiguration)を指定したほうがいいでしょう。

f:id:kkamegawa:20160520064150p:plain

終わりに

これ中身はJSONらしいのですが、簡単にエクスポートしてほかの人の環境でも持ってこれる方法あるのかな…。あるような気がするんだけど。