SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート(AD)

VMwareの事例で学ぶ、ソフトウェア構成管理ツール「PERFORCE」とオールフラッシュアレイ「EMC XtremIO」による開発サイクル高速化

PERFORCEとEMC XtremIOの組み合わせによるクラウドファーストの開発事例

  • このエントリーをはてなブックマークに追加

自社とゲストのビジネススピード向上のために
~VMwareの開発環境における改革

 クラウド上に新しい仮想環境を展開するためには、ソースコードを作り、インストールし、その上にホストとしてゲストの仮想マシン、たとえばWindows Exchangeや、サーバなどを構築する。その後、End to Endでのテストが必要となり、ようやく開発者に渡して開発が行われ、デプロイ&テストとなる。かつてはクラウド上に新しい仮想環境を展開するために10分はかかっていた。それが現在の環境では数秒でできるようになったという。

 10分が数秒になったということは、小さな改善に思うかもしれない。しかし、当然ながら開発中にはテストも含め、このプロセスを幾度となく繰り返すことになるため、そこに時間がかかれば開発スケジュール全体に大きく影響する。つまり、この時間短縮は開発スピードに大きく貢献するというわけだ。

 なお、このスピード向上のためには、フラッシュストレージが有効であり、マルチノードで同時に80000ものVM上でノードを走らせ、さらに関係する複数名のオペレーションが簡単に管理できる必要があった。かつてはこれを担保するために100のサーバを用いていたが、拡張性に限界を感じていたという。現在約5000人のデベロッパー、さらにCIビルドが1日30000以上、また4箇所に開発拠点が設置されているが、どこも同じように快適に開発できる必要があった。各拠点によって待機時間がバラバラという状況は望ましくなかったというわけだ。

 Hu氏は、「XtremIOによって開発時はもちろん、テスト時も大きく時間を短縮することができました。さらに、バグレポートが迅速に開発側のもとに上がることで、いっそうの開発サイクルの短縮化に成功しました」とその成果について語る。そして、それはVMwareが提供する環境を利用するユーザにも大きな恩恵となることは違いない。

VMwareが実践したDevOps事例の課題と結果
VMwareが実践したDevOps事例の課題と結果

変化するQEの役割とテストの頻度

 VMwareが自社のため、そして製品を使うユーザのために開発環境を改革するために、2番目のアプローチとして掲げたのは「Dev Owns Quality(開発者が品質を所有する)」の考え方だ。

 これまでウォーターフォール型では、開発側がコードを完成させてからQE(クオリティエンジニア)のチェックを受けるという形だった。しかし、近年DevOpsが浸透し、開発側がクオリティを監視下におくようになったことで、コードに対する責任は開発側のものとなった。となれば、QEの役割として何をすればいいのか。Hu氏は「実にシンプルなこと」として、このように語る。

 「開発側が中期的なテスト、たとえばユニットテストや機能テストを行うとすれば、QEは長期的なテストを行います。たとえばパフォーマンスやストレステスト、また包括的なフレームワークを作ることなどが該当します」

 この開発側でのスピーディなテストとQEによる最適化により、QEから開発側への手戻りを削減するなど、効率化を図ることができる。その際、必要となるのが自動化だ。コードを自動的にチェックする仕組みにより、スピーディなテストが可能になるというわけである。なお、VMwareでは24時間サービスを提供しており、いつでも開発者をサポートする環境が整っている。開発スピードを担保することはもちろん、心理面でも安心を得られるというわけだ。

VMwareが取った、開発側が品質を担保する「Dev Owns Quality」というアプローチ
VMwareが取った、開発側が品質を担保する「Dev Owns Quality」というアプローチ

 そして最後、3番目のアプローチとして「Refactor Testing」が紹介された。ここでもテストのスピードについて言及。そして、その最適化のためにもバケタイズ(分類)テストが必要だという。VMwareの調査によると、開発の現場では長年同じテストを繰り返しており、それが普通であると考えられてきた。しかし、その中で有用だったもの、結果が得られなかったものを振り分けて効率化を図ることで、テスト回数を減らせたという。また、ハードウェアを限定することで、テストマトリックスを減らし、さらなるテストの効率性向上を実現した。

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
イベントレポート連載記事一覧

もっと読む

この記事の著者

伊藤 真美(イトウ マミ)

エディター&ライター。児童書、雑誌や書籍、企業出版物、PRやプロモーションツールの制作などを経て独立。ライティング、コンテンツディレクションの他、広報PR・マーケティングのプランニングも行なう。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/8699 2015/05/15 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング