目次


モバイル・アプリケーションでの DevOps の課題とベスト・プラクティス

モバイル・エンタープライズのための DevOps の 10 のベスト・プラクティス

Comments

この 5 年にわたり、ビジネス・アプリケーション・ユーザーの行動パターンの大きな変化に、多くの業界が大慌てで対応しています。その変化とは、全世界の膨大な数の人が、インターネットにアクセスするための第一の手段として、モバイル端末を使用するようになったことです。ユーザーの行動パターンの極めて重要な変化は、企業にとって、既存のビジネス・アプリケーションをモバイルでも使えるようにして、さらにモバイル端末固有の特性を利用できる新しい種類のアプリケーションを計画する大きな動機となります。IT 業界における大々的な進化の例に漏れず、このモバイルへの移行でも、最初の数年は需要を満たして市場での存在感を確立するための活動に追われ、アプリケーションの開発コスト、保守性、品質、そしてセキュリティーなどの戦略上の課題までは考慮されていませんでした。モバイル・アプリケーション市場が成熟し、市場参入への競争が落ち着いた今、これらの大局的なソフトウェア開発の課題に焦点を移せるようになっています。

この記事では、企業にモバイル・アプリケーションを統合する際の課題について検討し、モバイル DevOps のための 10 のベスト・プラクティスを紹介します。まず始めに DevOps について概説してから、DevOps の現場でモバイル・エンタープライズ・アプリケーションを統合するという具体的な課題 (そして、その必要性) をいくつか取り上げて説明します。その上で、継続的インテグレーション、アプリケーションのテストとモニター、そしてモバイル・アプリケーション・デリバリーを統合したワークフローで DevOps を実装するための 10 のベスト・プラクティスを紹介します。

DevOps とは何か?

「DevOps」とは、テクニックでもプロセスでもなく、アプリケーションの方向付けから本番稼働までのシームレスなアプリケーション・デリバリーを可能にするためのアプローチです。DevOps が登場する前は、企業組織では一般に、開発チームと運用チームを分けて維持していました。開発チームと運用チームの間でコミュニケーションを取ることも協力することもなかったことは、さまざまな形で企業の成長および革新への課題となりました。開発と運用が分離されていることは、アジャイル開発を導入した企業にとっても悩みの種となりました。アジャイル手法に従うと、開発、テスト、デプロイしなければならない新しいアプリケーションのビルド数が桁違いに増えるからです。それまでは、開発チームが新しいビルドを運用チームに提供するのは数ヶ月間隔だったのが、アジャイル開発を導入したことで、数時間ごとにビルドを生成し、これまでよりもはるかに高い頻度でリリース候補をデリバリーすることが可能になりました。

DevOps ムーブメントは、アプリケーションの継続的デリバリーに伴う課題により効果的に対処するために、開発チーム (Dev) チームと運用チーム (Ops) が協力するようになったことから始まりました。当初の目標は、運用の責務を「左シフト」することでした。つまり、ソフトウェア・デリバリー・ライフサイクルのかなり早い段階で、運用チームを関与させます。そうすることにより、開発チームは始めから運用上の懸念事項を念頭に置いて、アプリケーションをコーディングするようになります。実際に、DevOps はリーン開発の原則に従って継続的インテグレーションおよび継続的デリバリーのプロセスを効率化することにより、開発者と運用管理者の利害と知識を調和させます。

IBM は、DevOps を全体的な視点で捉えています。IBM が定義する DevOps とは、「継続的ソフトウェア・デリバリーによって、ソフトウェアの利用者が市場機会を捉え、顧客からのフィードバックを受け取るまでの時間を短縮するためのエンタープライズ機能」です。

この定義で鍵となる言葉は、継続的デリバリーです。継続的デリバリーとは、ソフトウェア・デリバリー・ライフサイクルのどの段階でも、ソフトウェアとそのソフトウェアを実行する環境を自動的に、あるいはオンデマンドでデプロイすることです。継続的デリバリーでデプロイするものには、単純な構成の変更から、漸進的に追加されるコード変更、データベース・スキーマの変更、環境の変更、あるいはスタック全体に至るまで、あらゆるものが考えられます。

モバイル・アプリケーションの場合の DevOps

エンタープライズ Web アプリケーションまたはモバイル・アプリケーションのどちらをコーディングしているとしても、DevOps が用いる基本原則は同じです。企業に DevOps を導入するときには、モバイル開発チームも組み入れてください。これは、モバイル・チームが企業で占める部分はほんのわずかである場合でも、モバイル・チームが従っているソフトウェア開発プロセスが異なる場合でも、必要なことです。特に、既存のエンタープライズ・アプリケーション/サービスのフロントエンドとしてモバイル・アプリケーションを開発するとしたら、DevOps にモバイル開発チームは不可欠です。この点は、コンシューマー向けアプリケーションであるか、社内用のアプリケーションであるかによって変わることもありません。

エンタープライズ・アプリケーション/サービスと直接やりとりするモバイル・アプリケーションは、DevOps ライフサイクルの第一級市民でなければなりません。そうなっていれば、エンタープライズ・アプリケーション/サービスに追加される新機能を、モバイル開発チームがモバイル・アプリケーションにシームレスに統合することができます。

モバイル DevOps の課題

DevOps の基本原則は、エンタープライズ・アプリケーションとモバイル・アプリケーションで共通していますが、モバイル・アプリケーションの場合、DevOps に特有の課題を突きつけます。これらの課題には、以下のものが含まれます。

  1. マルチプラットフォームのサポート

    モバイル・アプリケーションがターゲットとする環境は 1 つだけではありません。ほとんどのモバイル・アプリケーションは、複数の端末をターゲットにしています。つまり、さまざまな技術仕様、OS バージョン、フォーム・ファクターに対処しているということです。Android はフラグメント化されていることでよく知られており、Android 端末のベンダーごとに、そのベンダー固有の端末用にオペレーティング・システムがフォークされています (例えば、Android for Nexus、Android for Kindle Fire、Android for Nook など)。しかも、BlackBerry 10、Windows Phone 8、Ubuntu、Firefox などの新参者が、さらに Android 市場をフラグメント化するようになっています。同様に、かつてはまさに標準だった iOS にも、現在は複数のバリエーションがあります。従って、iOS アプリケーションは、iOS の複数のバージョン (iPhone 4S とそれ以前のフォーム・ファクター、iPhone 5 のフォーム・ファクター、iPad と iPad mini のフォーム・ファクター) をサポートしなければなりません。

  2. エンタープライズ・フロントエンドとしてのモバイル・アプリケーション

    モバイル・アプリケーション (特に B2C (企業対消費者間取引) または B2E (企業対従業員間取引) のエンタープライズ・モバイル・アプリケーション) には、通常、モバイル端末自体に関するビジネス・ロジックがほとんどありませんが、B2C や B2E モバイル・アプリケーションは、企業がすでに使用している 1 つ以上のエンタープライズ・アプリケーション (トランザクション処理システム、従業員 HR システム、顧客獲得システムなど) のフロントエンドとして機能します。図 1 に、このようなアプリケーションの一例として、内部に限られたビジネス・ロジックがあるアプリケーションの主要な部分を示します。

    図 1. LinkedIn モバイル・アプリケーションのアーキテクチャー
    LinkedIn モバイル・アプリケーションのアーキテクチャーを示す図
    LinkedIn モバイル・アプリケーションのアーキテクチャーを示す図

    出典: LinkedIn Engineering ブログ

    LinkedIn モバイル・アプリケーションは、実際にはバックエンドにある LinkedIn プラットフォームのフロントエンドであり、このバックエンドのプラットフォームに LinkedIn の Profile、Connections、Groups といったアプリケーションまたはサービスがあります。このモバイル・アプリケーションは、ネイティブ・アプリケーションまたはハイブリッド・アプリケーションとして複数のプラットフォームに配信されます。従って、バックエンドの LinkedIn プラットフォーム・サービスと併せて開発し、配信しなければなりません。この場合、DevOps にとって課題となるのは、企業のアプリケーションのすべてを総合的に考えて、これらのアプリケーションのビルドおよびリリースのプロセスとサイクルを調整することです。

  3. 継続的インテグレーションと継続的デリバリー

    モバイル・アプリケーションを短時間で市場に送り出すというビジネス・モチベーションは強力であることから、モバイル開発プロジェクトには、一般に極めて意欲的なスケジュールが設定されます。方向付けからデリバリーまでの期間は、数ヶ月、あるいは数週間に設定されることさえあるのが通常です。成功したモバイル・プロジェクトのほとんどでは、モバイル・アプリケーションを短時間でリリースしなければならないというプレッシャーから、アジャイル開発手法を採用しています。

    継続的インテグレーションと継続的デリバリーは、ほぼすべてのアジャイル・プロジェクトで重要な要素となります。開発者がアプリケーションに加えた変更は、直ちにターゲットとするモバイル・オペレーティング・システムのすべてに対応するように処理されなければなりません。モバイル・アプリケーションがハイブリッド実装またはネイティブ実装である場合は、アプリケーションの変更一式が開発者から提供されるたびに、そのアプリケーションのさまざまな種類のビルドを開始する必要があります。ビルドのセットアップおよび構成は、サポートされるモバイル環境ごとに異なります。これらの複数のオペレーティング・システムのビルドに対処するには、おそらく小規模なビルド・サーバー・ファームをプロビジョニングして使用できるようにする必要があるでしょう。

  4. アプリケーション・ストア

    通常、モバイル・アプリケーションを直接端末にデプロイすることはできません。モバイル・アプリケーションを入手するには、アプリケーション・ストアを通す必要があります。Apple は、このアプリケーション配布モデルを導入し、アプリケーションの開発者やベンダーが Apple 端末に直接アプリケーションをインストールできないようにしました。RIM などの端末メーカーも、このモデルに従っています。

    アプリケーション・ストアは、デプロイメント・プロセスに時間のずれを生じさせる要因でもあります。それは、開発者が必要に応じてアプリケーションの更新をデプロイすることができないためです。極めて重要なバグの修正であったとしても、アプリケーションの新しいバージョンは、アプリケーション・ストアにサブミットし、レビュー・プロセスを経ることになります。従って、継続的デリバリーは「サブミットした後に待機」するプロセスになります。

  5. 「プッシュ」型ではなく「プル」型のデプロイメント

    従来のデプロイメントのほとんどは、「プッシュ」型で行われています。プッシュ型であれば、Web アプリケーションでも、その他のサーバー・ベースのアプリケーションでも、運用部門が必要に応じて、アプリケーションの新しいバージョンをリリースできます。しかし、モバイル・アプリケーションの更新プロセスは、「プル」型です。プル型ではほとんどの場合、ユーザーが自らアプリケーションを更新することを選択しなければなりません。モバイル・アプリケーションの開発者は、アプリケーションを利用しているユーザーが端末上でどのバージョンを使用するかをコントロールすることは、ほとんどできません。これは DevOps の観点からすると、アプリケーションがやりとりするデプロイ済みのバックエンド・サービスでは、モバイル・アプリケーションの以前のリリースを引き続きサポートしなければならないことを意味します。

  6. コンシューマー向けアプリケーションの場合、失敗は許されません

    アプリケーションが星 1 つで採点されることほど、ブランドにとって手痛いことはありません。その評価がアプリケーション・ストアを媒体として広められるとしたら、それはなおのことです。アプリケーションが有償であろうが無償であろうが、コンシューマー向けモバイル・アプリケーションに不満を持つユーザーは、たちまち一般の人に知られて目立つようになります。Web サイトの問題についての苦情は、技術サポート・デスクに伝えられるものですが、モバイル・アプリケーションに関する不平は、誰もがわかるようにアプリケーション・ストアを通して広められます。モバイル・アプリケーションの品質を確かなものにするためには、その機能、ユーザビリティー、パフォーマンスを広範にわたってテストする必要があります。

モバイル DevOps のための 10 のベスト・プラクティス

モバイル・アプリケーションに特有の課題を踏まえ、モバイル・アプリケーションの場合の DevOps に推奨される 10 のベスト・プラクティスを提案します。これらのベスト・プラクティスは、大まかに以下の 3 つの機能カテゴリーに分けられます。

  1. 継続的インテグレーションと継続的デリバリー
  2. テストとモニター
  3. モバイル・アプリケーション・デリバリー

目標は、これらの 10 のベスト・プラクティスを適用して、モバイル・アプリケーションに特有の課題に対処すると同時に、上記の 3 つの機能を有効にするデリバリー・パイプラインを確立することです。

継続的インテグレーションと継続的デリバリー

  1. すべてのアセットにわたるエンド・ツー・エンドのトレーサビリティーを確保すること

    すべての開発アセットおよび QA アセットにわたって追跡できることの価値に、もはや疑問の余地はありません。モバイル・アプリケーション開発チームは、あらゆる開発アセット (コード、構成、スクリプト、コードとしてのインフラストラクチャー、テスト・スクリプト、設計ドキュメントなど) をエンド・ツー・エンドで追跡できるようにする必要があります。さらに、トレーサビリティーの範囲をモバイル開発アセットだけに限定するのではなく、モバイル・アプリケーションの統合先、接続先、あるいはアクセス先となるエンタープライズ・アプリケーション/サービスにまで広げなければなりません。

  2. 継続的インテグレーションを実践すること

    アジャイル開発のプラクティスは、「継続的インテグレーション」を促します。継続的インテグレーションとは、頻繁にビルドを実行して、新しいコードを継続的に、他のチームが前に開発したコードに統合することです (これは、モバイル・アプリケーションとエンタープライズ・アプリケーションの両方に当てはまります)。継続的インテグレーションにより、ある開発チームによって提供されたコードが、別の開発チームによって提供されたコードやモジュールと連動することが確実になります。モバイル・アプリケーションの場合、統合は継続的に行われるのが通常ですが、開発中のモバイル・アプリケーションがアクセスするバックエンドを構成する非モバイル対応のサーバー・サイドのコンポーネントとも、定期的に統合を行う必要があります。

    モバイル・アプリケーションの場合、複数の開発チームが中央のビルド・サーバーと統合サーバーを利用して、ターゲットとするすべてのモバイル・プラットフォームに対応するモバイル・アプリケーション・コードを共有します。ビルドと開発のプロセスを自動化することにより、サポートするすべてのプラットフォームに対し、中央のビルド・サーバー (サーバー・ファーム) 上で、継続的イングレーションのためのビルドを高い信頼性の下で迅速に行えるようになります。

  3. サポートするネイティブ・モバイル OS SDK バージョンごとに、ビルド領域と統合領域を分けて維持すること

    モバイル端末におけるフラグメント化は、主要なモバイル・オペレーティング・システムが 4 つ (iOS、Android、Blackberry、Windows Phone) に分かれているにとどまりません。これらのオペレーティング・システムのそれぞれも、内部でフラグメント化されています。例えば、Apple は iPad をサポートするために iOS をフォークしています。Android のバリエーションは、ほぼ端末の種類の数だけあります。RIM の BlackBerry 10 は、レガシー BlackBerry OS と限られたつながりしかない、まったく新しいオペレーティング・システムです。Windows Phone 8 は、Windows Phone の以前のモデルが大々的に作り直されたものです。さらに、Ubuntu や Firefox などから、新しいモバイル・プラットフォームもいくつか登場してきています。このことから、モバイル・アプリケーション開発者は、ターゲットとするプラットフォームのそれぞれと、そのバリエーションをサポートするために、アプリケーションのバリエーションを複数作成しなければなりません。それは、1 つのプラットフォームだけをターゲットにしている場合でも同様です。すべてのモバイル・アプリケーションに、複数のバージョンの SDK が必要になります。

    ターゲット・プラットフォームごとに、コードと固有の機能を確実に切り離すには、開発者はプラットフォーム固有のモバイル・アプリケーションのバージョンごとに、開発の「流れ」を分けて維持管理する必要があります。この分離に必要となるのは、ターゲット・プラットフォームごとに、ビルド領域と統合領域を分けて維持管理することです。Android アプリケーションを例にとると、開発者は Kindle Fire、Nook HD、Nexus、その他のオペレーティング・システムのそれぞれについて、別々の流れで開発する必要があります。

  4. 自動化されたビルド・スクリプトとデプロイ・スクリプトを使用すること

    モバイル開発者は、IDE を使用して手作業でビルドを実行するという方法に慣れています。場合によっては、ターゲット・プラットフォームごとに手作業でビルドを実行することもよくあります。ビルドの複雑さと数が増えてきたら、開発者はスクリプトを使用して、必要に応じて個別のビルド・サーバー上でビルドを実行するという方法で、自動化されたビルドをセットアップすることができます。ビルド・スクリプトを管理し、コードと同じようにバージョンを割り当てて、いつでも、どのチーム・メンバーでも、各ビルドを再現できるようにしてください。

テストとモニター

  1. シミュレートした端末上または実際の端末上で、可能な限り自動化して各ビルドを徹底的にテストすること

    テストの自動化は、モバイル・アプリケーション開発がエンタープライズ・アプリケーション開発に遅れをとっている領域です。ほとんどのモバイル開発者は、実際の端末上ではなく、シミュレーター上で広範囲にわたるテストを行います。シミュレーターでのテストでさえも、その大半は手作業です。開発のスピード、そしてモバイル開発に伴うアジャイルな性質を考えると、品質を確保するための唯一確実な方法となるのは、自動化された機能リグレッション・テストです。サポート対象のプラットフォームとフォーム・ファクターは数えきれないほどあることから、手作業で十分なテストを行うことは不可能であるためです。さらに、エンタープライズ・アプリケーションの場合には、それが顧客向けか従業員向けかに関わらず、品質の低さは許容されません。

    自動化されたテスト・ツールを使用して、すべてのアプリケーションを SDK が提供するシミュレーター上だけでなく、サポートする実際の端末のすべてでテストしてください。

  2. モバイル・アプリケーションのテスト中に使用可能になっていないバックエンド・サービスは、仮想化してシミュレートすること

    モバイル・アプリケーションは、迅速な開発プロセスに従います。そのため、バックエンドのエンタープライズ・アプリケーションおよびサービスと比べると、モバイル・アプリケーションのリリース回数は多くなりがちです。このような迅速な開発により、モバイル・アプリケーションは、技術的には常にエンタープライズ・アプリケーションの先をいっています。つまり、まだバックエンドのエンタープライズ・アプリケーションおよびサービスではサポートしていない、先進の機能を備えているということです。バックエンド・サービスを使用できるとしても、それらのサービスに対してテストを行うには、コストがかかったり、リソースが必要になったりする場合があります。例えば、SaaS サービスでは通常、従量課金制の料金が発生しますが、この料金はテストにも適用されます。同様に、System z (メインフレーム) でホストされるサービスには、MIPS 料金がかかります。開発チームがこの問題を解決するには、バックエンド・サービスを仮想化 (シミュレート) するという方法があります。モバイル・アプリケーションがやりとりしなければならない実際の機能の動作をシミュレートすれば、このアプリケーションがやりとりする必要があるアプリケーション、サービス、データ・ソースからなるエコシステム全体を仮想インスタンスとして使用することができます。このような方法を使えるようにすることで、モバイル・アプリケーションのテストや、モバイル・アプリケーションによるやりとりのテストを迅速に行えるようになります。しかも、これらのサービスやアプリケーションの実際のインスタンスを実行するために必要なハードウェア・リソースも節約することができます。

  3. デプロイ後のモバイル・アプリケーションとバックエンド・サービスのパフォーマンスをモニターすること

    モバイル・アプリケーション開発者にとって、テスト環境では十分なパフォーマンスを発揮するのに、フィールドでは十分なパフォーマンスを発揮できないアプリケーションほど、大きな問題はありません。モバイル・アプリケーションのパフォーマンスを低下させる根本原因には、信頼性に欠けるネットワーク状態、メモリー不足、バッテリー残量の低下、データ損失などがあります。これらすべての条件を予測してラボでテストできるとは限りません。従って、開発者は使用中のアプリケーションのパフォーマンスを常にモニターできるようにすることが不可欠です。そのようなモニターは、アプリケーション内で行うことも、アプリケーションがやりとりするアプリケーション・スタックのサーバー・サイドで行うこともできます。

    究極的なパフォーマンス問題は、ユーザーが実際に使用しているときに、モバイル・アプリケーションが実行を停止することです。障害の発生時に「必ず」収集しなければならないコンテキスト情報 (位置情報データや端末の特性など) を収集するロジックをアプリケーションに追加しておくと、開発者は、障害の根本原因を突き止めて修正するのに十分なデータを入手することができます。モバイル・アプリケーションには、異常終了を捕捉して分析するロジックを組み込んでおくことが不可欠です。

モバイル・アプリケーション・デリバリー

  1. モバイル・プロビジョニング・プロファイル、証明書、API キーに対して一元化したガバナンスを採用すること

    アプリケーションをアプリケーション・ストアにサブミットする場合も、内部または外部アプリケーションが提供する API を使用する場合も、開発者や企業は、ベンダーが発行するプロビジョニング・キーまたはプロファイル・キーによって、アプリケーションの真正性と所有権を識別します。これらのキーは、ストアまたは API に対する許可証としての役割を果たします。一般に、個々の開発者は独自のキーを入手して、開発を行うためにそのキーを使用するものです。しかし、最終的なアプリケーションをリリースするときには、これらの個人用のキーをすべて削除し、正式な企業のキーに置き換えてください。企業のキーおよびプロファイルは保護しておき、正式なアプリケーション・リリースでのみ使用するようにします。モバイル・ガバナンスのプロセスは、明確に定義して管理しなければなりません。何よりも重要なのは、企業キーへのアクセスを制限することです。アクセス権の付与は、セキュリティーとプライバシー両方の問題であり、厳重なガバナンスを必要とします。

  2. 仮想アプリケーション・ストアを使用して端末へのデプロイメントをテストすること

    モバイル・アプリケーションをモバイル端末にプロビジョニングするには、ベンダーのアプリケーション・ストアを介して行うしか方法はありません。通常、アプリケーションは人の手による承認プロセスを経た後、アプリケーション・ストアに加えられます。ストア内のアプリケーションは、ユーザーに「購入」してもらう必要があります。ユーザーがアプリケーションを購入すると、ユーザーの端末にアプリケーションがプッシュされます。このプロセス全体をテストするために、開発チームは「専用の開発アプリケーション・ストア」を使用することができます。これらの仮想アプリケーション・ストア (「参考文献」を参照) は、実際のアプリケーション・ストアの動作をシミュレートすることにより、開発者がアプリケーションをサブミットして端末にプロビジョニングするまでのプロセスを効果的にテストできるようにします。

  3. ユーザーのフィードバックを、機能強化のリクエストおよびユーザー事例の形にすること

    モバイル・アプリケーションには、アプリケーション・ストアを介した固有のフィードバック・メカニズムがあります。アプリケーション・ストアでは、ユーザーがアプリケーションを評価し、フィードバックを書くことができます。好感度の高いアプリケーションは、星 4 つ、または星 5 つの評価を受けることが多く、あまり人気がないアプリケーションは、たいていは星 1 つか 2 つの評価を受け、場合によっては評価に否定的なフィードバックを伴います。モバイル・アプリケーションのフィードバック・ループは、他のどのプラットフォームでも一元管理された正式なメカニズムとして使用することはできません。開発者が一般にデスクトップ・アプリケーションの問題の気付くのは、ユーザーが技術サポートに電話するか、あるいは開発者がモニターしているフォーラムにコメントを残した場合のみです。モバイル開発チームは、アプリケーション・ストアでのフィードバックと評価を注意深くモニターし、そのフィードバックを将来のユーザー事例、機能強化、そしてソフトウェアの改善に取り入れてください。この貴重なフィードバックを最大限に利用することが、モバイル・アプリケーションの継続的な改善には不可欠となります。

まとめ

モバイル・アプリケーションに専用の DevOps などというものはありません。DevOps は、フロントエンドのモバイル・アプリケーションからミドルウェア、バックエンド・サーバー・コンポーネント、そしてデータ・ストアに至るまで、あらゆるアプリケーションとコンポーネントに有効なアプローチです。これらのコンポーネントのすべてで継続的デリバリーを実現するために、DevOps のプラクティスと原則を企業の開発チームと運用チームのすべてに適用してください。

ただし、モバイル・アプリケーションには、対処しなければならない特有の要求事項と課題があります。この記事で紹介したモバイル・エンタープライズのための DevOps の 10 のベスト・プラクティスは、そのようなモバイル特有の要求事項に対処します。これらのベスト・プラクティスの目標は、モバイル・アプリケーションの開発、品質保証、そして運用プラクティスを、標準のエンタープライズ・アプリケーションと調和させることです。これらのベスト・プラクティスを適用することで、企業はモバイル開発チーム全体で DevOps を導入し、高品質のモバイル・アプリケーションを提供することや、継続的な改善と革新を可能にすることができます。


ダウンロード可能なリソース


関連トピック

  • モバイル開発のための DevOps」(Michael Galpin 著、developerWorks、2013年9月): DevOps がモバイル・アプリケーションの継続的インテグレーションと継続的デリバリーを統合するというニーズにどのように対処するかを、特にモバイル・アプリケーションのさまざまなバージョンを多様な端末にデプロイする場合について理解してください。
  • From manual to continuous automated deployment of mobile Worklight applications」(Joel Cayne 著、IBM developerWorks、2014年2月): この記事では、IBM UrbanCode Deploy を使用して、IBM Worklight モバイル成果物の DevOps デプロイメント・ソリューションを定義する方法を紹介しています。
  • Leveraging web content in a mobile app using Worklight」(Vinod Appajanna、Stefan Hepper 共著、IBM developerWorks、2014年3月): IBM WebSphere Portal および IBM Web Content Manager の内部で実行される動的ルールと Web コンテンツ・メタデータを IBM Worklight モバイル・アプリケーション内で使用する方法について、実際のケース・スタディーを用いてデモします。
  • Add IBM Mobile Quality Assurance to your mobile quality regimen」(Leigh Williamson 著、IBM developerWorks、2014年3月): 今すぐ IBM Mobile Quality Assurance を使い始めてください。これは、開発者が手作業によるモバイル・アプリケーションのインタラクション・テストを行うのを支援する、クラウド・ベースのツール一式です。
  • How to test mobile applications with Rational Test Virtualization Server」(Manjula Sogi 著、IBM developerWorks、2014年1月): Rational Test Virtualization Server、Rational Test Workbench、Rational Quality Manager を使用してモバイル・アプリケーションのテストをエンド・ツー・エンドで行う方法をステップ・バイ・ステップで紹介する記事を読んでください。
  • Mobile testing with IBM Rational Test Workbench」(Pragati Maheshwari 著、IBM developerWorks、2013年8月): IBM Rational Test Workbench を使用して Android モバイル・アプリケーションをテストする実践的な方法を調べてください。
  • Getting started with IBM Worklight: Worklight をセットアップして使い始めてください。
  • Rational Test Virtualization Server: 複雑なテスト環境を迅速に提供し、仮想化されたサービス、ソフトウェア、アプリケーションをデプロイして、単純化された効率的なテストを行ってください。
  • IBM developerWorks の Mobile Frontier ブログMobile development ゾーンにアクセスして、この記事と同様のトピックを取り上げている記事を見つけてください。
  • IBM Rational Test Workbench: モバイル・アプリケーション、リグレッション・テスト、統合テクノロジー、そしてパフォーマンス・テストとスケーラビリティー・テストに対応する包括的なテスト自動化ソリューションを試してください。
  • Rational Test Virtualization Server: 仮想化されたサービス、ソフトウェア、アプリケーションをデプロイして、単純化された効率的なテストを実現してください。
  • IBM UrbanCode Release: ライフサイクル・モデルのすべての段階を通してリリースを計画、実行、追跡できるようにするソフトウェアをダウンロードしてください。
  • IBM Mobile Quality Assurance: 高品質のモバイル・アプリケーションの継続的デリバリーを可能にします。
  • IBM UrbanCode Deploy: 開発、テスト、本番の各環境へのアプリケーション、ミドルウェア構成、およびデータベース変更の実装を編成し、自動化します。
  • IBM Rational Test Virtualization Server: アプリケーション・テストの依存度を排除して、セットアップの時間とインフラストラクチャー・コストを削減してください。
  • Worklight Developer Edition: このオープンで包括的なアプリケーション開発プラットフォームを使用して、HTML5、ハイブリッド、そしてネイティブの各モバイル・アプリケーションをビルド、実行、管理してください。
  • IBM Rational solution for Collaborative Lifecycle Management: アプリケーション・ライフサイクル・マネジメント(ALM) 機能を統合して、チームの生産性を向上させてください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Mobile development, DevOps, Rational
ArticleID=977513
ArticleTitle=モバイル・アプリケーションでの DevOps の課題とベスト・プラクティス
publish-date=07172014