Visual Studio App CenterでGitHubのPull Requestを効率よく対応しよう
とあるPull Request画面
Pull Request画面で以下の赤枠の文言を見かけたことはありませんか？
これは継続的インテグレーションがセットアップされていませんよ、という情報です。 「are available」のリンクをクリックするとGitHub MarketplaceのCIカテゴリに遷移します。
GitHub Marketplaceの CI カテゴリ
GitHubのMarketplaceで提供されているCIツールが表示されます。
ここではApp Centerを選択します。するとApp CenterのGitHub Appページが表示されます。
App CenterのGitHub App
このページの下部に以下のような画面があります。
プランを選ぶところですが、ここではFreeを選択して「Install it for free」をクリックしてインストールしましょう。
App CenterのGitHub Appを反映させるリポジトリを選択します。 リポジトリを選択した場合は対象のリポジトリに対してVSAppCenterのプロジェクトを作成します。
VSAppCenterのプロジェクト作成・ビルド設定
対象OSとPlatformを選択しプロジェクトを作成します。
その後、ビルド設定が開くのでビルド設定を実施します。
ビルド設定画面の「Save」ボタンを選択し設定を保存してください。 これでVSAppCenterとGitHubとの連携ができました。
GitHubのPull Request画面での確認
設定したプロジェクトと関連付けたGitHubリポジトリへ新たにPull Requestを投げてください。PullRequestの内容をVSAppCenterがビルド開始し、以下のようにVSAppCenterでビルドしている状態が見れるようになりました。
ビルドやテストが完了すると以下のように表示が変わります。
「Details」のリンクからVSAppCenterの画面へ遷移して詳細なビルドログを見ることが可能です。
Checks APIについて
なぜGitHubでCIサービスの詳細なタスク状況が分かるようになったかというとGitHubからChecks APIというものが提供されたかです。 従来はインテグレーション実施後にビルドの成功／失敗ステータスだけが表示されていたのですが、本APIによりステータスの詳細が表示され、必要に応じてビルドプロセスの再実行もGitHubのユーザーインターフェイス内で完結することができるようになります。 どこからでも利用できるAPIではなく、GitHubAppが利用できるAPIのようです。 現在対応しているのは以下の4つのようです。
最後に
Pull Requestをすぐにビルド・テストすることでレビューアの負担が軽減し、開発の生産性が上がるのではないでしょうか。 また、Checks APIにより色々なCIサービスとGitHubが繋がることで、GitHubがますます便利になることを期待しています。
Visual Studio App CenterについてAndroid Test Night、iOS Test Nightで話してきました。
3月19日のAndroid Test Night、および、3月26日のiOS Test NightにてVisual Studio App Centerについて話してきました。
内容は、1月に登壇した春のApp Center祭りの内容の焼き直しです。
www.slideshare.net
www.slideshare.net
以下、まとめて説明します。
なぜ、CI/CD環境が必要か？
- 開発者がコーディングに集中するため
GitリポジトリにPushする前に、プロダクトの対象となるOS×画面サイズの環境パターンでのテストを開発者のマシンで実施すると、開発者がコーディングにかける時間が失われます。開発者は主たる環境パターンでのみテストを通してPushし、CI/CD環境で複数のパターンを実施することによってコーディングに専念できます。
- 各開発者のマシン環境によってビルドの差異ができることを防ぐ
各開発者のマシン環境は同じようにしているつもりでも差異が発生していることがあります。その影響で開発者Aのマシンでビルドしたものでは正常に動作するのに開発者Bのマシンでビルドしたものでは異常終了する、ということが起きるかもしれません。開発チームがCI/CD環境を正とし、この環境でテストが成功することが対象機能（ストーリー）の実装完了とすることで誤ってバグのある機能をリリースするリスクを軽減できます。
CI/CD環境をオンプレミスで構築すると．．．
CI/CD環境をオンプレミスで作成すると色々な費用が掛かります。
- ハードウェア費用
- ソフトウェア費用
- 監視費用
- 維持メンテ費用
- テスト端末費用
運用方法によってはオンプレミスよりもクラウドサービスを利用したほうがコストも安く、開発者にも負担がかからない環境が作れるかもしれません。
Visual Studio App Centerの主な機能
ビルドやデリバリーだけでなく、Push通知などの機能があります。 料金プランを見ると無料でビルドに240 ビルド時間 (分)/月使えるというのはすぐに消費してしまう印象ですが、ビルドが強制的にタイムアウトするまでの時間が30分というのは比較的長めです。 配信、分析、プッシュ通知等は無料で色々使えて良い感じです。
対応プラットフォームもそれなりに充実している印象です。 将来的にはサーバサイドアプリもビルド・テストしてAzure等にデプロイできればよいなぁ、とは思います。
各機能の説明はスライドを見てください。
Azureとの連携
Visual Studio App Centerの分析機能は物足りないのですが、Azureへイベントログを流して、そのログをApplication Insightsで可視化すると詳細な分析ができて良いと考えます。
また、Blob Storageにイベントログを保存して、色々なアプリと連携することも可能です。
App Center Client
App Centerのほとんどの機能はAPIとして公開されており、APIをたたくことでコードベースで管理することも可能です。 個人的にはGUIよりもコードで管理している方が安心できます。
色々なシステムと連携して自動化できると嬉しいです。
最後に
今回、Android Test Night、iOS Test Nightで話してみて(HockeyAppは知っていても)Visual Studio App Centerを知らなかった人が多かった印象です。 Microsoft以外の開発環境である各モバイルOSのネイティブ言語やReactNativeなどのクロスプラットフォーム環境に対応しているので、もっとMicrosoftの既存顧客向け以外にも宣伝すればよいのに、と思いました。
余談
Flutterに対応してくれないかなぁ、と思ったらFlutter側がVSAppCenter向けのSDKを作っている模様．．．
【追記】
ということでXamarinコンサルタントがFlutter向けに作成してContributeしている模様。> Flutter側がVSAppCenter向けのSDKを作っている模様．．．
— Atsushi Eno (@atsushieno) 2018年4月24日
Flutter側がそんなものを作るわけはなくてですね、作っているのはXamarinコンサルタントの人のようです https://t.co/bzHN0nDdZG
「JXUGC #24 春の App Center 祭り」 にて登壇しました。
2018/01/20に開催された、「JXUGC #24 春の App Center 祭り」で登壇してきました。
jxug.connpass.com
今回のイベントを主催したJXUGはXamarinのユーザグループですが、Visual Studio App CenterはC#に限らず色々な言語でのビルドをサポートしているので、せっかくだからAndroidはJava、iOSはSwiftでビルドする際の話をしました。
ビルドする対象は公式サンプルアプリを選択しました。
github.com
github.com
自作アプリも考えたのですが、
私の資料がVSAppCenterを使い始めるきっかけになってくれれば幸いです。
CI/CDツールの紹介なので、公式のストア（GooglePlay、AppStore）にアップロードするところまでやりたいと考え、それぞれの開発者登録をしました。
せっかく開発者登録したのでストアに掲載できるようなアプリを今年は開発したいと思います。CI/CDはもちろんVSAppCenterを使います。
今回、30分のセッションなのに資料が90スライド以上になってしまってのでテンポよく進めなきゃな、と思っていたのですが、先に発表していた大田一希さんがネタを潰してくれていたので、部分部分を飛ばすことができて何とか30分に収まりました。ありがとうございます。
明日の App Center 祭りでは App Center 概要について話します。ここでどれだけ後続の人たちの話すネタを潰していくかが問われていると思って挑みます！
— かずき@66.8kg (@okazuki) 2018年1月19日
Xamarin.Formsでスマートウォッチアプリ開発
はじめに
本エントリーは Xamarin Advent Calendar 2017 11日目のエントリーです。
スマートウォッチアプリ開発というとAndroid Wearかwatch OSを思い浮かべ、本記事を開いた方もいらっしゃるのではないでしょうか。ですが、その両OSともにXamarin.Formsでの開発に対応していません。
以下のRoadmapにもありません。
forums.xamarin.com
そもそも、スマートウォッチアプリのようなUIが特殊で機能が限定されているものにXamarin.Formsは向かないような気もします。そんな中、Xamarin.Formsでスマートウォッチアプリが開発できる環境が誕生しました。それがTizen.NETです。 本記事ではTizen OS搭載スマートウォッチアプリを.NETで開発する環境構築方法を紹介します。
Tizen.NETについて
Tizenの.NET対応については、こちらの記事をご覧ください。
本記事執筆時点の最新バージョンはTizen 4.0 M2です。
このバージョンからWatch用のエミュレータも提供されています。
Tizen.NETの環境構築
こちらの記事にて説明があります。
前提条件
- 1.5GB以上のディスクスペース
- Visual Studio 2017：以下のオプションは必須
- .NET desktop development
- .NET Core cross-platform development
- Java Development Kit (JDK) 8
- OpenJDKは非対応
エミュレータの必要条件
Visual Studio Tools for Tizen のインストール
- 拡張機能と更新プログラムから「Tizen」をキーワードに検索
- 検索でヒットした「Visual Studio Tools for Tizen」をインストール
Tizen Baseline SDK のインストール
- ツール > Tizen > Tizen Package Manager を選択してダイアログを表示
エミュレータイメージのインストール
- ツール > Tizen > Tizen Package Managerを選択してダイアログを表示
- 4.0 WEARABLE (Preview)の行のINSTALLボタンを押下
以上で準備が整いました。
Tizen.NETアプリの作成
- Visual Studio の新規プロジェクトからVisual C# > Tizen > Cross-Platform > Blank App(Xamarin.Forms)を選択
- Project Wizardにて、Profileの項目で「Wealable(preview)」を選択
これでアプリができました。ソリューションエクスプローラーの構成は以下になります。
${ソリューション名}.Tizen.Wealable のプロジェクトを右クリックしてデバッグ > 新しいインスタンスを開始 でエミュレータが立ち上がり、アプリが起動します。
以上でXamarin.FormsでTizenOSのスマートウォッチアプリの開発環境が準備できました。
Xamarin.Forms以外でのTizenアプリ開発
Xamarin.Formsで提供されるUI部品はOSネイティブのそれと比べるとプアであることは否めません。
Tizen用アプリでXamarin.FormsよりもリッチなUIを使いたい、TizenのネイティブUIを使いたい、という要望もあるかと思います。安心してください、あるんです。
最新の開発環境ではXamarin.Formsの他にElmSharpとTizen.NUIを選択できます。
- ElmSharp
- Tizen NativeのUI FrameworkであるEFLをベースに開発したもののようです。
- Tizen.NUI (Natural User Interface)
- Tizen Nativeで用意されているAPIの.NETのラッパーです。
去年のConnect();2016で発表された際は、UI部分をXamarin.FormsでまかないNativeのUI部品は可能な限り対応する、という後ろ向きな内容でしたが、1年経った今、NativeのUI部品も充実してきました。
Windows 10 Mobileの新規機能が事実上終了した今、第３のOSとしてTizenに注目があつまっていることでしょう。
Tizen.NETの正式リリースが待ち遠しいですね。
Tizenの.NET対応について
5月27日の「JXUGC #23 Xamarin 無料化一周年記念勉強会！」にて、Tizenの.NET対応について登壇してきました。
発表した資料はこちらです。
以下、資料の補足です。
Tizenとは？
Tizenの特徴
.NET対応する前のTizenはC/C++ベースとHTML5+JavaScriptベースの2つの開発方法が用意されていました。
TizenにはTizenコンプライアンスというものが定義されており、Device Profileの共通コンポーネントを「Tizen Common」レイヤーで管理することでDevice Profileの依存性を軽減できます。
アップストリーム・ファーストは素晴らしい考えだと思います。
バグを直した独自のソースを管理するのは非常にコストがかかるものです。
アップストリーム・ファーストによって、常に最新の安定板をOSS側のリポジトリから取得できます。
Tizenの状況
Linux Foundationの公式プロジェクト
TizenはSamsungの所有物ではなく、Linux Foundationで開発が進められているオープンソースソフトウェアです。
スマートフォン
徐々に展開先を増やしているようです。
ロシアについては断念せざるを得ない事態がありますが後述します。
スマートウォッチ
スマートウォッチはAndroidWearのシェアを上回っており、日本でも展開されているので期待が持てるのではないでしょうか。
スマートTV
スマートTVについては最近のシェアを確認できるものが見つからなかったのですが、Samsungのテレビ販売台数が10年連続世界一なことも考えると期待は持てると思います。ただし、日本はB-CASの仕組みがあり一度撤退しているので、再参入してくるかは疑問です。
車載用OS
TizenにはLiMo Foundationの流れからあるモバイル端末OSとしての役割以外に、Automotive Grade Linux（AGL）の流れからある車載用OSとしての役割も重要でした。
しかし、車載用OSについてはTizenとは異なるUnified Code Base(UCB)へ移行することとなってしまいました。Tizenの車載用OSについては現在は開発が停止しています。
TizenOS誕生までの流れ
この流れで注意しなくてはいけないのはSailfish OSです。
前述のロシアでTizenの展開が中止となったのはロシア政府がAndroidの代替OSとしてSailfish OSを認可したからです。
ロシア以外でも中国、ボリビアなどの、Google主導のAndroidの独占に疑念を持つ国がSailfish OSに興味を持っています。
ひょっとしたら第3のOS第4のOSはTizenではなく、Sailfish OSとなるかもしれません。
Tizen Assosiation
現在のBoard Membersは上図の通りです。 そして、Tizen Assosiationのパートナープログラムに加入している日本企業は、Access、KONAMI、NTT DATA、Panasonicなどがあります。 まだ、日本市場でワンチャンあるかもしれません。
Tizen Mobile App Incentive Program for 2017
Samsungがスポンサーになっているインセンティブプログラムです。
期間中TOP100を独占すれば900万ドルがゲットできるのですが、そのような状況にはなっていません。
日本での状況
芳しくない状況です。
特に書籍についてはGOOGLE WAVEの悲劇が思い出されます。
Tizenちゃん、かわいいよ、Tizenちゃん．．．
Tizenの初めての.NET対応
MonoTizen の誕生
Kitsliano Software社のコーポレートスローガンってカッコいいですよね。
この会社はMono for Sailfish、MonoHTML5にも着手していました。が、完成はしていないようです
MonoHTML5はTizenのHTML5実装にヒントを得ていたようです。
MonoTizen の開発延期
開発開始からわずか2か月で開発延期となったのは、本当に驚きです。
MonoTizen の開発延期の理由
Kitsliano SoftwareのメンバーはMonoTizenの開発を延期した今でもEathereumのクライアントライブラリをTizenやSailfish向けに開発しているなんて本当にLinuxが大好きなんでしょうね。
Tizen.NETの誕生
Tizenの.NET対応について
2016年11月16日にTizenの.NET対応が発表されてから定期的にPreview版がアップデートされています。
Tizenの.NET対応に最も驚いた人
MonoTizenのリードプログラマだったDimitar Dobrev氏がTizenの.NET対応に加わりたい旨を表明しています。
CppSharpの貢献者でありQtSharpの開発者である彼が加わることで、Tizenの.NET対応が加速することを期待しています。
なぜ.NET対応をするのか
Tizen ProjectではC言語ベースとHTML5ベースで開発する際の課題を.NETの採用により解決できると考えています。
Tizen.NET アーキテクチャ
前述のTizenの特徴で表示した図の左側に.NET関連の機能が追加されました。
TizenではMonoではなく.NET CoreをRuntimeとして選択しています。
.NET Coreを用いてTizen Platform-Specific APIはP/Invoke(プラットフォーム呼び出し)により.NETのコードから、TizenのC/C++のAPIを呼び出しています。
Xamarin.AndroidやXamarin.iOSと同様にネイティブの機能を呼び出しています。
Tizen Platform-Specific API 構成例
DevDaysのハンズオンアプリなどでみんな大好きなText-To-Speechの機能についてリポジトリを見てみると、Interopフォルダ内に「Interop.Libraries.cs」と「Interop.Tts.cs」が存在します。ここでP/Invokeの処理を実装しています。
実際にC#でのコーディング時にアプリのコードから呼び出すのはTizen.Uix.Ttsフォルダ内にあるクラスとなります。
Tizen .NET Developer Preview1
最初にリリースされた際の状況です。 正直、このままでは実用に耐えうるものではありませんでした。
Tizen .NET Developer Preview2
Preview2ではOpenGLViewが不完全とはいえ、Formsの部品は一通りそろえています。固有のAPIについても31pkgから49pkgに増えました。
SmartTV向けの開発もできるようになりTool類も充実し始めました。
Tizen .NET Developer Preview3
Preview3では開発環境の充実もさることながら、Tizen固有のForms部品であるTizen.Xamarin.Forms.Extensionとして、ボタン、ポップアップ、グリッド、カレンダービューなどが実装されたことが特徴です。
本来、共通部品を用意することが主目的なはずのFormsで独自部品のみ用意するとはUIをXamarin.Forms頼りにしているTizenならではかと思います。
Tizen .NETのRoadmap
Preview3でほぼ機能は実装したので、Tizen4.0 M1 リリースに向けてブラッシュアップをしていることでしょう。
Tizenの .NET関連のリポジトリ
定期的にコミットが観測されており、開発は進んでいるようです。
Tizen 関連情報
Tizen関連のサイトのURLです。
Tizen ExpertはTizenの状況を幅広く知るために良いサイトです。
資料の説明については以上です。
.NETラボでAI×Office365についてLTしてきました。
報告にずいぶん間があいてしまいましたが、4月22日の.NETラボ勉強会でAI×Office365についてLTしてきました。
LTのタイトルは「AI時代のOffice365」です。
MicrosoftはAIに注力しておりOffice365製品・サービスにもAIが活用されています。
日本マイクロソフトも働き方改革第2章によってOffice365で蓄積されたデータからAIによる気づきを活用することで働き方の質を目指すと発表しています。
その営みの中でOffice365を活用すべきと判断する企業が増えてくることを期待して、Office365開発を学ぼうという趣旨の資料です。
今回はLTの5分用資料だったのですが、活用方法、開発方法等もまとめて30分～40分くらいのセッション資料にはまとめたいと思っています。
初心者歓迎XamarinのLT会！Xamarin入門者の集い #2 でLTしてきました。
ずいぶん間があいてしまいましたが、4月17日に「初心者歓迎XamarinのLT会！Xamarin入門者の集い #2」 でLTしてきました。
一般枠で申し込んでいたのですが急用の方のキャンセルで前日の段階でLT枠が空いたのでLT枠に乗り換えました。
そして私が1日で作成するとしたらどんなテーマを選ぶかですが、当然Tizenですよね。
ちょうどPreview3が出た直後で、それを紹介したいこともあり、さらっと作成できました。
Preview3で一通り機能を出したという認識になったのか、Gitのログを見ても新しいAPIを実装するよりもすでに実装したAPIのテコ入れをしている感じです。
Tizen.NETはTizen4.0で正式リリースとなります。待ち遠しいですよね。
