ラクーンのCI/CDへの取組みの現状とこれから（２）

こんにちは。たむらです。

今回は前回に引き続き「ラクーンのCI/CDへの取組みの現状とこれから」と題した第２回目です。第１回は「Capistrano」によるデプロイの効率向上のお話でした。第２回目は「Selenium」によるテスト自動化の話とシステムとツールを統合管理してくれるCIツール「Jenkins」のお話です。それではいってみましょう！

サイト監視ってカッタルイ～「Selenium」登場～

弊社はサイトを通してビジネスをしているのでサイトがダウンするとビジネスが成り立たないことになってしまいます。その為、当然のことですがサーバの死活監視、プロセス監視、HTTP通信監視等色々な監視を複合で行なっています。その監視の１つとして、「お客様が実際に利用するメインの導線となる機能が正しく機能しているかを確認する」監視という結構泥臭いことを行なっています。例えばスーパーデリバリーで言えば、以下の様なフローを実施することで確認をしています。

1. 小売店様のスーパーデリバリーサイトへのログイン

2. 商品検索～閲覧

3. 商品Aの注文

4. 出展企業様の管理画面へのログイン

5. 商品Aの受注処理～出荷処理

6. 商品Aの返品・返金処理

さてこの監視ですが、以前はその他の監視業務等と併せて外部委託していましたが、現在はSeleniumを利用して行なっています。

SeleniumはWebブラウザを使ってWebアプリケーションをテストするツールとしてこれまたメジャーなツールです。FireFoxアドオンのSeleniumIDEにて簡単にテストシナリオを作成することができます。また、Selenium2(WebDriver)となってからは各種ブラウザをネイティブに操作できる様な作りとなりだいぶ様変わりしました。
正直、2008年頃は挙動が安定しなかったり動的なページのテストが上手くできなかったりして余り使えてなかったのですが、Selenium2が発表された頃に再度利用してみて「これはイケそう！」とまた使ってみる気になった経緯があります。

現時点ではまだSelenium1系のSeleniumRCを使ってテストを運用しています。その為、テストシナリオはSeleniumIDEを利用してベースを作成した後、記述を見直した上でテストケースとしています。というのは、利用したことがある人はご存知だと思いますが、SeleniumIDEの記録するシナリオはロケーションの指定の仕方が微妙なものがある為です。また、表示の度にidが変わる様なものもSeleniumIDEだとほぼ確実にidでロケーションを指定してしまうため、それらは汎用的な形に指定を変更してあげる必要があります。

■TestCaseの例(上記「3.商品Aの注文」の一部)■

～～～
<!-- 商品リストの左上商品をクリック -->
<tr>
  <td>clickAndWait</td>
  <td>xpath=(//a[starts-with(@href, '/p/r/pd_p/')][1])</td>
  <td></td>
</tr>
<!-- ログイン済み検証 -->
<tr>
  <td>assertElementNotPresent</td>
  <td>xpath=(//img[@alt='ログイン'])</td>
  <td></td>
</tr>
<!-- 数量ボタンを押下 -->
<tr>
  <td>click</td>
  <td>id=input_1_up</td>
  <td></td>
</tr>
<!-- カートに入れるボタンを押下 -->
<tr>
  <td>click</td>
  <td>css=a.vmiddle.add-cart-item > img[value="カートに入れる"]</td>
  <td></td>
</tr>
<!-- Ajax処理表示待ち -->
<tr>
  <td>waitForVisible</td>
  <td>link=カートへ進む</td>
  <td></td>
</tr>
～～～

ちなみにSelenium2は現在まだ評価中ですが、最終的にはクロスブラウザチェック等も行なっていきたいと考えている為いずれ置換えて行く予定です。ただ、上記の例でも使っているような "waitForVisible" 等のメソッドは自作する必要があり、一通りのベースを作りこんで検証した上でと考えています。

ルーチン業務に時間を取られるのはしんどい！～「Jenkins」登場～

さて、上述のSeleniumによる監視ですが、自動定期実行のために何かしかの仕組みが欲しいところです。勿論cronでも機能的には満たせるのですが、今後のSelenium利用シーンの拡大を考慮して、より運用や管理が行い易いものを望んでいました。
そこで Jenkins の登場です。Jenkinsは言わずと知れたオープンソースの継続的インテグレーションツールの代表格です。コミットトリガによるビルドやスケジューリング、タスクの依存関係構築等がGUI上から簡単に行うことができ、更にプラグインの追加により他にもたくさんの機能を管理対象とすることができます。

Seleniumを用いたテストの自動定期実行もプラグインを利用することで簡単に設定が可能です。手順はたったコレだけです。

(1) Jenkinsのプラグインで、「Hudson SeleniumHq plugin」をインストール

(2) 「新規ジョブ作成」からジョブを登録し、実行間隔等を定義

(3) 「ビルド手順の追加」-「SeleniumHq htmlSuite Run」を選択し実行するTestSuiteを指定

■SeleniumHQ htmlSuite Run の定義例■

プラグインとして用意されている割には、細かな設定もかなりの範囲で行えて痒い所に手が届く作りになっています。

例えば、上記では[browser]で起動すべき実行形式の指定を変更していたり、デバッグモード設定やログ出力等の指定ができる様に[other]にパラメタを積み込んだりしています。

必要に応じてレポート出力ができる「Selenium HTML report」やエラー通知用に「Jenkins Email Extension Plugin」等のプラグインを入れるのも良いでしょう。

尚、SeleniumをJenkinsサーバ自身で動かそうとしていて、且つJenkinsサーバがLinuxでGUIが無い場合、実行にはXwindowやXvnc等の設定をしておく必要があります。

この様にJenkinsはインストール後、ほぼ選択と入力をするだけで簡単に始めることができます。基本的にはビルドを中心にしてその前後処理を肉付けしていく感じで徐々にやれる範囲を拡大して行くような流れで構成を作っていくことになると思います。

■Jenkinsの画面イメージ■

ラクーンのCI／CDのこれから

ここ迄現時点で行なっている幾つかの取組みを書いてきましたが、ん～・・・まだまだ全然不十分ですね。ワンクリックデプロイやテスト自動化という言葉には程遠い様に見えます。Jenkinsの強みも有効に利用できているとは言えません。
ただ、第１回の冒頭でも書きましたが、既存である程度の規模のシステムができ上がっている状態からこれらを適用していくのは、一朝一夕では行えません。また、継続的インテグレーションや継続的デリバリはここ迄やれば完了というものではなく、「継続的」と付いている通り常に改善／改良を加えていくものだと認識しています。

そんな訳で、「千里の道も一歩から！」。今後も一歩ずつ着実に成果を積み上げて作り上げていこうと思っています。

ちなみに今構想しているこれからの取組みはこんなことです。

1. デプロイの完全自動化

　・バージョン管理システムとの完全な連携

　・ロールバックをワンクリックでできる仕組みの構築

　・ビルド環境の確立

　・リリース単位のバッティングによるデグレードを抑止する仕組み

2. テスト自動化

　・クロスブラウザ検証の（ある程度の）自動化

　・テストシナリオの充実

3. システム構成管理の簡易化(環境の構築がより簡便に実施できる様にする）

4. Jenkinsによるデプロイやルーチン業務の統合

5. QAの半自動化

今回取り上げたツールの他にも色々なCI/CDツールが選択できる状態にあり、それらも上手く取り入れていくことでどれも実現が可能なものだと思っています。

終わりに

CIやCDについての取組みは直接システムの利用者の満足に繋がるものではありません。ですが、開発チームのサポートとして目に見えた改善を感じることができるところですし、何より新しいツール等を駆使して、いかに自分で考えながら最適解を探すかという楽しみもあり、とてもやり甲斐を感じることができるものです。

自ら考えて構築することやCI/CDに興味をお持ちの方、是非一緒に働いてみませんか？？

・・・と、最後に求人を入れつつ、以上、２回に渡ってラクーンのCI/CDについてのお話でした。

ラクーンのCI/CDへの取組みの現状とこれから（２）

サイト監視ってカッタルイ ～「Selenium」登場～

ルーチン業務に時間を取られるのはしんどい！ ～「Jenkins」登場～

ラクーンのCI／CDのこれから

終わりに

関連記事

サイト監視ってカッタルイ～「Selenium」登場～

ルーチン業務に時間を取られるのはしんどい！～「Jenkins」登場～