iOSアプリケーションの継続的デリバリー   〜エンタープライズ品質のiOSアプリケーションを目指して〜
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

iOSアプリケーションの継続的デリバリー 〜エンタープライズ品質のiOSアプリケーションを目指して〜

on

  • 2,505 views

2013/11/7に行われたiOS Enterprise & Developers Conference 2013の資料です。 ...

2013/11/7に行われたiOS Enterprise & Developers Conference 2013の資料です。

iOSアプリケーションの継続的デリバリー
〜エンタープライズ品質のiOSアプリケーションを目指して〜

Statistics

Views

Total Views
2,505
Views on SlideShare
1,988
Embed Views
517

Actions

Likes
9
Downloads
20
Comments
0

4 Embeds 517

http://numeha.hatenablog.com 505
https://twitter.com 9
http://mym.corp.yahoo.co.jp 2
http://cloud.feedly.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

iOSアプリケーションの継続的デリバリー 〜エンタープライズ品質のiOSアプリケーションを目指して〜 Presentation Transcript

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