継続的インテグレーションを始めるための基礎知識：グリーはいかにしてJenkinsを導入したのか（1）（2/2 ページ）

» 2013年02月13日 18時00分公開

[岡崎隆之，グリー]

前のページへ 1|2 　　　　　　

どのCI製品／サービスを利用するかの3つのポイント

　どの製品あるいはサービスを使うか最初は、次のような視点で考えると良いでしょう。

【1】導入が簡単か

　まだCIを実施したことがないようであれば、ツールを導入するだけのために多くの労力をかけるよりもまずは導入して、経験を積むべきです。多機能／高機能であるよりも、まずは導入が簡単であるかどうかを判断基準にすると良いでしょう。

　CIツールのためのサーバを用意できないようであれば、クラウドサービスの利用も選択肢として考えられます。

【2】サポート体制について

　CIを開発に取り入れるためには、手厚いサポートが欠かせません。オープンソース製品であれば、コミュニティがどの程度活発に活動しているかを確認しておくと良いでしょう。

【3】連携するシステムがサポートされているか

　バージョン管理システム、チケット管理システムなど開発チームが利用しているツールやシステムとの連携ができるかどうか確認しておきます。CIツールを利用する際のユーザー権限など、管理が必要であればアイデンティティ管理システムとの連携も可能かどうか確認が必要です。

グリーでのJenkins導入

　グリーではCIのツールにJenkins使っています。Jenkinsを利用している理由は下記の通りです。

無償ですぐに使い始められる
日本含めコミュニティが活発
さまざまなプロジェクトに柔軟に対応できる

　CIはなるべくスモールスタートで始めて、経験や実績を積むことが重要です。多機能を使いこなすのはプロジェクトやチーム全体がCIに慣れた後のフェイズと考えると良いでしょう。

　Jenkinsのインストールや基本的な使い方は、次のような記事やドキュメントが参考になります。

　また、Jenkinsはコミュニティが活発で、勉強会なども盛んに開催されています。導入の実績や、導入のテクニック、問題解決の方法といった情報が手に入れやすいのは、とても貴重なことです。Jenkinsに関する情報は次の場所から参照できます。

Jenkins導入前の大きな問題点

　グリーではJenkinsの導入によって解決した問題はいくつもありますが、Jenkins導入初期に解決した問題のうち代表的なものを紹介します。

作業の属人化

　開発作業は対策をせずにいると、どんどん属人化して他の開発者が作業できなくなることがあります。AndroidやiOSなどのネイティブアプリのビルド手順はグリーでのJenkins導入初期には属人化が顕著な問題でした。

　AndroidやiOSアプリは開発が進むにつれ複雑化します。ビルド手順書を作成することで、ある程度の作業は属人化を回避できますが、XcodeのバージョンアップやAndroid SDKのバージョンアップなどの外的要因によっても日々手順が変化します。

　あるレベルを超えると、iOSやAndroidのビルドを正確に実行して実行バイナリを作るという職人芸が必要な領域に入っていきます。

　このため、社内で最新のAndroidアプリやiOSアプリを確認したい場合には、必ず職人の技術者に頼まねばならず、また職人技を持った技術者もたびたびアプリをビルドするためだけに作業を中断されることになります。

　このためグリーでは、まずJenkinsでAndroidアプリやiOSアプリをビルドできるようにしました。AndroidアプリやiOSアプリのビルドについては、次回詳しく説明します。

　Jenkinsでアプリがビルドできるようになると、最新のアプリを試したい人はJenkinsから最新のアプリをダウンロードして使えるようになりました。これにより、職人技を持った技術者はビルドのための割り込みから解放され、ビルドのノウハウはJenkins上に集約されます。

　手順書などドキュメントの更新によって、別の技術者が作業を開始するまではビルドができないといった問題がなくりました。

　一方、Jenkinsによるビルドであれば最新のアプリをテストしたい人がJenkinsでビルドする段階で問題が見つかります。このように、ビルド手順だけでもCIは非常に大きな効果を発揮します。

成果物と課題の管理

　JenkinsでiOSやAndroidアプリをビルドする以前は、技術者がビルドしたパッケージをファイルサーバ上に置いて、プロダクトマネージャやデザイナへ渡していました。

　ファイルサーバへのアップロード、ファイル名の変更などには、ささいなミスが発生しやすく、ファイルの管理は煩雑で面倒くさいものでした。場合によっては、旧バージョンのファイルを誤って削除するなど紛失するケースもありました。

　ファイル名を正しく変更しなかったために、旧バージョンのアプリでテストを行うなど作業ミスも発生しやすく手戻りが多く見られました。

　例えば最新のv4では修正済みのバグが、古いv3でテストされていたために課題として報告され原因の追究に無駄な時間が発生するといったことが、しばしば発生していました。

　一方Jenkinsでビルドを行うと、各ビルドの成果物は自動的にJenkinsによって管理されます。プロダクトマネージャやデザイナはJenkinsサーバから最新のビルドをいつでもダウンロードできるようになります。

　またビルドごとに番号が自動的に付与されますので、技術者とプロダクトマネージャ、デザイナの間で同じバイナリが確実に使われていることを説明しやすくなります。JIRAやRedmineなどのチケット管理システムのチケットにビルド番号を記載することで、より確実にビルドと課題解決の結び付きを管理できるようになりました。

1度回り始めれば必要不可欠なJenkins

　グリーでの導入は今回紹介したような、スマートフォンのネイティブアプリのビルドから段階的に導入していきました。

　「CIを導入したいがなかなか進まない」という経験をお持ちの方は多くいると思います。Jenkinsのようなツール群は1度回り始めれば必要不可欠とも思えるような仕組みを持っていますが、利用経験のない方からすると得られるメリットのイメージが既存の仕事のやり方やワークフローを変えるコストをなかなか超えることができないために積極的になれないことが多いようです。

　今回紹介したように、まずは簡単な作業からCIができる準備を整え、開発チームならびに周囲の関係者に使ってもらうと良いでしょう。

　ある程度使ってもらった段階で、「もっと、こういうことができないのか？」というような問い合わせが入るようになれば大成功です。