Upload
naoki-umehara
View
2.310
Download
7
Embed Size (px)
DESCRIPTION
2013/11/7に行われたiOS Enterprise & Developers Conference 2013の資料です。 iOSアプリケーションの継続的デリバリー 〜エンタープライズ品質のiOSアプリケーションを目指して〜
Citation preview
梅原 直樹iOS EDC 2013: iOS Enterprise & Developers Conference 7/11/2013
Naoki UMEHARA
iOSアプリケーションの継続的デリバリー
〜エンタープライズ品質のiOSアプリケーションを目指して〜
僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては
ならない
梅原 直樹うめはら なおき
Twitter:@numehahttp://numeha.hatenablog.com/
#iosedc
Developers Summit 2013
http://www.slideshare.net/numeha/ricoh-ucs-for-ipad
株式会社 リコー
新規事業を生み出すために
クラウド関連とiOS関連の
ソフトウェア開発リーダとして活動しています
※ちなみにiOS歴は約1年半です
よろしくお願いします
RICOH UCS(Unified Communication System)
1.
2011年8月22日ビデオ会議市場に新規参入
クラウドやビデオチャット市場を含めると2020年8,000億円市場に
http://businessnetwork.jp/Detail/tabid/65/artid/1262/Default.aspx
簡単さ・使いやすさを追求した
少人数(約5名)向けの
ポータブル型のテレビ会議システム
P3000
http://www.ricoh.co.jp/ucs
ポリコム
ソニーシスコ
パナソニック
リコーその他
ビデオ会議メーカシェア
http://www.seedplanning.co.jp/press/2013/2013032701.html
2012年
5位!!
iPad版
http://www.apple.com/ipad-mini/overview/
iPad版(2013/1/31 Release)
iPhone版(2013/9/10 Release)
コミュニケーションの幅を拡大
⚠当日は
ムービーを流しました
ビジュアル・コミュニケーション
各拠点間
外出先 自宅 移動中
他にもメンタルヘルスの支援の一貫でiPadを利用
http://www.mitsubishicorp-foundation.org/reconstruction/case/file28.html
お客様同士の横の繋がりによる導入
RICOH UCSいいらしいよ
よし導入しよう
エンタープライズの世界でネットワーク効果の兆候
いずれにしてもお客様の
ビジネスに直結したコミュニケーション
手段として利用されている
近場の病院との情報共有研修医の育成のための会議本部+10拠点で定例会議
海外拠点との会議・・・・・
エンタープライズでのコミュニケーションビジネス
↓お客様のビジネスを止めてはならない
↓
ここにもビジネスチャンスがある
エンタープライズ品質
2.iOSアプリケーションの
継続的デリバリー
iOS
iOS Apps : 900,000Store Accounts : 575,000,000
2013年6月現在
Apps will Automatically Updatein iOS7
〜常に最新版のアプリをユーザが利用可能〜
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Objective-Cの開発者が急増
http://www.tiobe.com/content/paperinfo/tpci/index.html
http://www.businessinsider.com.au/ios-is-the-platform-for-enterprises-2013-3
http://www.businessinsider.com/apple-is-winning-the-mobile-enterprise-2012-7
リーン・スタートアップによるライバルの増加
※ 大企業もやらないと死ぬhttp://thebln.com/wp-content/uploads/2011/09/Eric-Ries-The-Lean-Startup.jpg
どこで戦うのか
モバイルファースト×
クラウドファースト×
ビジネスモデル
それはお客様の業務に
なくてはならないものになっているか
特にエンタープライズ市場ではこのような状態に早く出来るのかが鍵。そしてその状態を維持できるのか
iOSアプリケーションの継続的デリバリー
〜エンタープライズ品質のiOSアプリケーションを目指して〜
僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては
ならない
僕たちは価値のあるソフトウェアを
早く継続的にデリバリーしお客様を満足させなくては
ならない
iOSアプリはどのくらいのスピードでリリース可能なのか
XCode iTunes Connect App Store
App Review
Ave:7daysPackageSubmit
最高で1ヶ月で約4回
1年間で約50回アップデートが可能
(実際にリリースするかは置いておいて)
このくらい継続的にデリバリーが可能な仕組みを作らなければならない
(実際にやるかやらないかは置いておいて)このくらい継続的にデリバリーが可能な仕組みを作らなければならない
Me
Me
Me
Me
ただ、2ヶ月半
App審査にかかり全く継続的にリリースできないケースもありますw
★1.0.0
2013年 1 2 3 4 5 6 7 8 9 10 11 12
★1.0.1
★1.1.0
★1.1.1
★1.2.0
★1.3.0
★1.5.0
★2.0.0
★2.0.1
★2.1.0
★2.2.0
★2.3.0
RICOH UCS for iOSのリリース
(機能UP&不具合修正で)
1年間で12回のリリース
リリースのリズムを作る
これが多いか少ないかは置いておいて
http://www.flickr.com/photos/odolphie/2397582359
http://www.amazon.co.jp/gp/product/images/4048707876/ref=dp_image_text_0?ie=UTF8&n=465392&s=books
ビジネスの主導権を得るために
http://www.allaboutagile.com/7-reasons-why-continuous-delivery-needs-to-be-a-business-initiative/
ユーザを早期に獲得する競争力あるプロダクトを早く実現する
http://www.flickr.com/photos/56155476@N08/6660135637
ビルド・デプロイ・テスト・リリース
ビルド デプロイ テスト リリース
小さく繰り返す
リリースまでのパイプライン
コードのコミットをしてからミスなく自動的に頻繁にリリースしたい
お客様に価値を継続的にデリバリーする唯一の方法
自動化
要するにとことん自動化する
(⚠App申請だけは手動)
http://morguefile.com/archive/display/4737http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg
•軌道修正
•不具合を減らす
•お客様、セールスの改善要求
•突然のApp審査ルール変更!!
小さく・早く・簡単にリリース
いつパイプラインを作るか
★1.0.0
2012 2013 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12
★1.0.1
★1.1.0
★1.1.1
★1.2.0
★1.3.0
★1.5.0
★2.0.0
★2.0.1
★2.1.0
★2.2.0
★2.3.0
●プロジェクト
開始
プロジェクト開始時にものがなくても仕組みを作る
そうすれば1stリリースまでプロセスがテストされ
その後のアップデートのリズムができる
僕たちははじめにリリースまでのパイプラインを作った
http://www.flickr.com/photos/49547334@N02/4725090871
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
価値のあるソフトウェアを作る
〜協調性を重視する〜
早く継続的にデリバリー〜完全自動化する〜
僕たちは
価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては
ならない
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
Developer Test Engineer
Leader
Team
製品の品質について責任を持つお客様に提供する価値を考える受け入れテストを自動化する
コードの品質について責任を持つお客様に提供する価値の高い
ものから開発する
Developer
Test Engineer
協力する
価値のあるソフトウェアを作る
〜協調性を重視する〜
役割は違うけれども
のは同じ
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
僕たちは
価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては
ならない
これがFeature
それはお客様の業務に
なくてはならないものになっているか
特にエンタープライズ市場ではこのような状態に早く出来るのかが鍵。そしてその状態を維持できるのか
再び...
僕たちは
最小限の機能で市場価値を生み出せるのか
いまやるべきなのか後でもいいのか
MMFMinimum Marketable Feature
Feature1
Feature2
Feature3
Feature4
Feature5
Feature6
Feature7
Feature8
これがMMF
お客様に提供する価値の優先度
これだけで市場価値を生むことが出来るのか
RICOH UCS for iOSのMMFモバイルユーザとして、
開催中のP3000 の会議に途中参加して映像と音声で相手とコミュニケーションしたい、それは会議の開催場所でなくても参加したいからだ
最初に書いたラフスケッチ
お客様に聞いてみた
結果:好感触
ここでダメならそこで終了
Feature1
Feature2
Feature3
Feature4
Feature5
Feature6
Feature7
Feature8
お客様に提供する価値の優先度
実装の優先度 < 顧客に提供する優先度
どこで1st release
するかはビジネス判断
小さく作って
大きく育てる
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
Featureシナリオ/ステップ
Featureテストコード
はお客様視点を持って仕様を作りながらそれを受け入れるテストコードの自動化をするTest Engineer
一つのFeatureに対するお客様に価値を与えるシナリオを作る
それが実際に自動で動くコードを書く
繰り返しながら改善する
Background: Given the following contacts exist: | device | another_device | subscription | ask | | ios1 | ios2 | both | | And "ios1" go to contactlist view And "ios2" go to contactlist view
Scenario: "ios1" can join conference Given "ios3" go to contactlist view And the following accounts start conference: | device | | ios2 | | ios3 | Then "ios1" should see the presence of "meeting" within row of "ios2" When "ios1" touch the row of "ios2" Then "ios1" should be on video view And "ios1" should see 3 participants And "ios1" should not see the private meeting image
iOS1とiOS2の2台のデバイスが
コンタクトリスト画面にいる
iOS3のデバイスがコンタクトリスト画面
にいてiOS2とiOS3が会議を
始める
iOS1からiOS2は会議中にみえ
iOS1がiOS2をタッチすると会議に参加する
Featureシナリオ/ステップ
自然言語は非開発者でも読めるので仕様書にもなって一石二鳥
どういう条件で、どういう時に、どうなるのか
https://speakerdeck.com/phodgson/beyond-uiautomation
Stepの部品化素人でもかけるテストを目指して
組み合わせるだけで新たなシナリオに
⚠ただし、iOS7だと実機では動かない
http://www.testingwithfrank.com/
FrankとCalabashを両方動かして良いとこどり
https://rubygems.org/gems/calabash-cucumber
⚠当日は
ムービーを流しました
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
KiwiGHUnitOCMock
etc
作りながら仕様を決める
Featureテストコードでは実現できない内部ロジックのテストをする
一つのFeatureを実現する設計をして、シナリオ/ステップを満たす実装をする
仕様はあくまで仮説であってゴールするときに決まる
最小単位のFeatureを動かしながら価値を確かめる
コードに問題があれば都度発見される
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
Featureテストコード
開発者テスト
リリースビルド
受け入れビルド
一つのFeature一つのBug
毎にPull Request
人の世界
機械の世界
PUSHをトリガにコードをpull
そして継続的デリバリーへ
Developer
Test Engineer
何か問題があれば通知
git pluginxcode plugin
最低限のビルドはこれだけでいける
※ 使えるプラグインは少ないのでこれ以上は自分でスクリプトを作る 単体テスト、カバレッジ、レポートファイル変換等
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
設計 実装 開発者テスト
Developer
Test Engineer
製品品質を確保する
ビルドに成功すると自動でipaファイル作成そして自動で複数のデバイスに自動でインストール
fruitstrapで各端末のidentifierを指定してインストールor
instruments
受け入れビルド
Runon
Device
ビルドサーバ
×
Devices iPad, iPhone, iPod Touch
OS×
iOS6, iOS7
Network Proxy, Low Bandwidth, etc
異なるiOSデバイス、異なるOS、異なるネットワーク環境で受け入れテストを常に実行
※ お客様の様々なネットワーク環境を想定する
ここまでやってエンタープライズ品質
ビルドサーバ
iPhone
iPod Touch
iPad
iOS6 & 7
⚠当日は
ムービーを流しました
iOS Simulator Limitation⚠
シミュレータでは動くけど、実機だとxxxは防ぐ
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
コード品質を確保する
テスト件数コード行数カバレッジ
警告数etc
コードの内部状態を徹底的に可視化
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
価値のあるソフトウェアを作る
〜協調性を重視する〜
早く継続的にデリバリー〜完全自動化する〜
これを繰り返す
0.1リリース
0.2リリース
0.3リリース
0.4リリース
そのリズムが継続的なデリバリーを可能にする
http://www.flickr.com/photos/seanhobson/4272482225
★1.0.0
2012 2013 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12
★1.0.1
★1.1.0
★1.1.1
★1.2.0
★1.3.0
★1.5.0
★2.0.0
★2.0.1
★2.1.0
★2.2.0
★2.3.0
●プロジェクト
開始
先をみた開発ができている
iOSアプリケーションの継続的デリバリー は一日にしてならず
まとめ
僕たちは価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなくては
ならない
リリースのリズムを作る
http://www.flickr.com/photos/odolphie/2397582359
ユーザを早期に獲得する競争力あるプロダクトを早く実現する
http://www.flickr.com/photos/56155476@N08/6660135637
要するにとことん自動化する
(⚠App申請だけは手動)
http://morguefile.com/archive/display/4737http://cdn.morguefile.com/imageData/public/files/m/mconnors/preview/fldr_2003_06_18/file0002046882848.jpg
僕たちははじめにリリースまでのパイプラインを作った
http://www.flickr.com/photos/49547334@N02/4725090871
リリースビルド
単体テスト
結合テスト
受け入れビルド
Runon
Device
受け入れテスト
リリース
Feature概要
Featureシナリオ/ステップ
Featureテストコード
Developer
Test Engineer
設計 実装 開発者テスト
価値のあるソフトウェアを作る
〜協調性を重視する〜
早く継続的にデリバリー〜完全自動化する〜
Developer
Test Engineer
協力する
価値のあるソフトウェアを作る
〜協調性を重視する〜
役割は違うけれども
のは同じ
MMFMinimum Marketable Feature
最小単位のFeatureを動かしながら価値を確かめる
コードに問題があれば都度発見される
×
Devices iPad, iPhone, iPod Touch
OS×
iOS6, iOS7
Network Proxy, Low Bandwidth, etc
異なるiOSデバイス、異なるOS、異なるネットワーク環境で受け入れテストを常に実行
※ お客様の様々なネットワーク環境を想定する
ここまでやってエンタープライズ品質
そのリズムが継続的なデリバリーを可能にする
http://www.flickr.com/photos/seanhobson/4272482225
梅原 直樹iOS EDC 2013: iOS Enterprise & Developers Conference 7/11/2013
Naoki UMEHARA
iOSアプリケーションの継続的デリバリー
〜エンタープライズ品質のiOSアプリケーションを目指して〜ご清聴ありがとうございました