CROOZ株式会社
鈴木 優一
CROOZにおける
JENKINS活用事例
自己紹介
• 鈴木優一
• Team 開発推進という部署で全社の開発
を効率化させるために必要なツール及び
仕組みの開発・保守・運用を行ってます
CROOZが提供するサービス
CROOZは、ソーシャルゲームを軸に、世
界中にインターネットサービスを提供す
るエンターテインメント企業です
本日のアジェンダ
• はじめに
• CROOZにおけるプロダクト開発スタイル
• 開発・保守・運用の諸問題
• Jenkinsを導入しようと考えたキッカケ
• Jenkinsの活用事例
• 導入効果
• 今後の展開
はじめに
はじめに
本日はJenkinsというツール自体の話はしません。
本日はJenkinsをどのように活用し、日々の開発・
保守・運用で抱える業務課題の解決に活用するか
について共有したいと思います。
今日はテスト自動化の話もしません。
CROOZにおける
プロダクト開発スタイル
CROOZにおけるプロダクト開発スタイル
それは
たとえリリース直前でも仕上がりに納得がいかな
ければ、他の案件からエンジニアをかけ集めてで
も、リリースまでに納得のいくモノに仕上げる
“オモシロカッコイイ”をツクルために、リリース
ギリギリまで、全社員一丸となりトライ・アンド
・エラーを繰り返すこと。
CROOZにおけるプロダクト開発スタイル
この開発スタイルを満たすために行っていること
• コーディングスタイルの共通化
• 運用の共通化
• 上記を実現する自社フレームワークの構築
CROOZにおけるプロダクト開発スタイル
この3施策によりプロダクト開発チーム間での
人的リソースの移動を容易に行える
チームの垣根を超え、より良いサービス実現の
ためにギリギリまで品質にこだわることができる
開発・保守・運用の
諸問題
開発・保守・運用の諸問題
細かな問題は様々だが最も大きな問題は
CROOZの開発スタイルを実現するうえで重要な
「コーディングスタイルの共通化」が行われに
くくなっていること
1日に頻繁に行われる本番へのデプロイの過程
で本来不要なファイルが誤って更新されてしまう
ことが発生したこと
開発・保守・運用の諸問題(原因)
問題が発生する原因について考えてみた
• 共通化されているルールは複雑すぎる
確かに可読性、パフォーマンスの観点からは
共通化すべきだが、覚えなければならないこ
とが多く、古株の社員しか対応できない。
開発・保守・運用の諸問題(原因)
問題が発生する原因について考えてみた
• 事業の急拡大に伴い、プログラマが急増した
ルールが複雑すぎる上に、様々な前職を持つ
プログラマが急増したため、個々に自分が正
しいと考える実装方法が行われている。
超属人化している
開発・保守・運用の諸問題(原因)
問題が発生する原因について考えてみた
• ルール違反やオペミスを引き起こす疑いのある
コードや設定をプログラマにフィードバックす
るしくみが無い。
運用が性善説で設計されている。
問題点をプログラマに伝える仕組みが必要
開発・保守・運用の諸問題
解決のための施策
• 現実的に覚えられないルールなら、覚えるので
はなくルールから外れているものを機械的に検
知し、可視化することでプログラマに伝える。
• 同じ考え方で、オペミスを引き起こす疑いのあ
るコードや設定を機械的に検出し可視化するこ
とでプログラマに伝える。
JENKINSを導入
しようと考えたキッカケ
JENKINSを導入しようと考えたキッカケ
特にJenkinsにこだわっていたわけではない。
前節で説明した要件を少ない構築工数で満たせる
れことができればToolとしてはどれでもよかった。
JENKINSを導入しようと考えたキッカケ
その上でなぜJenkinsを導入したかというと…
• 構築が容易
過去の経験より
• 各種プラグインが充実している
可視化のための各プラグインが充実している
• ジョブ管理ツールとして利用できる
ジョブ管理ツールとしても利用できる
JENKINSを導入しようと考えたキッカケ
その上でなぜJenkinsを導入したかというと…
• 実装言語に限らず全社横断で利用が可能
CROOZではNativeアプリも開発しているため
実装言語ごとにSlaveノードを立てられると
都合が良い
• ドキュメントが豊富
CIツールとして歴史があり、調査が容易
JENKINSを導入しようと考えたキッカケ
本来ならば自動テストまで行いたいが…
まずは既存課題の解決が第一。
課題が解決し、共通化してからのテスト出ないと
テストケースが膨れてしまうだけ…
CROOZにおける
JENKINS活用事例
事例① 規約チェックの自動化
PHP_Code Sniffer × VenusBase による規約チェック
自動化及び可視化
• PHP_Code Sniffer
http://pear.php.net/package/PHP_CodeSniffer
コーディング規約に沿っているかどうかを
チェックするツール
• VenusBase
自社フレームワーク『Venus』専用のコーディン
グ規約定義スクリプト
事例① 規約チェックの自動化
システム構成図
リポジトリサーバ Jenkins
Venus
Base
PJT
Source
pull pull push
eclipce PDT + Code Sniffer
plugin
PJT
Source
polling
pull
Check Style
phpmd
cpd
reporting
feedbackcoding
事例① 規約チェックの自動化
事例① 規約チェックの自動化
システム構成図
リポジトリサーバ Jenkins
Venus
Base
PJT
Source
pull pull push
eclipce PDT + Code Sniffer
plugin
PJT
Source
polling
pull
Check Style
phpmd
cpd
reporting
feedbackcoding
コーディング規約違反
については直接エディ
タ上でWarningとError
と分けてプログラマに
通知
事例① 規約チェックの自動化
システム構成図
リポジトリサーバ Jenkins
Venus
Base
PJT
Source
pull pull push
eclipce PDT + Code Sniffer
plugin
PJT
Source
polling
pull
Check Style
phpmd
cpd
reporting
feedbackcoding
コーディング規約違反
については直接エディ
タ上でWarningとError
と分けてプログラマに
通知
Jenkinsではコーディン
グ規約違反のほか潜在
バグとなりうる可能性
のある箇所についても
集計、レポーティング
事例② 除外ファイルの更新漏れの自動通知
リモートシェル × Gitlist による除外ファイルの更
新漏れの自動通知
• 除外ファイル
STG環境から本番環境にデプロイする際に本番に更
新したくないファイルを記述するリスト。同時に複
数のリリースやバグ修正が走る際に記述が必要。
• GitList
https://github.com/klaussilveira/gitlist
PHP製Gitブラウザ。表示のみ可能。
事例② 除外ファイルの更新漏れの自動通知
システム構成図
STGサーバ Jenkins
rsync
reporting
feedbackfix
デプロイ設定
除外
ファイル
git add
git commit
mail sendupdate
事例② 除外ファイルの更新漏れの自動通知
システム構成図
STGサーバ Jenkins
rsync
reporting
feedbackfix
デプロイ設定
除外
ファイル
git add
git commit
mail sendupdate
除外ファイルの前回か
らの更新差分をGitリ
ポジトリで管理し、リ
ンクURLを生成してプ
ログラマにメール送信
事例② 除外ファイルの更新漏れの自動通知
システム構成図
STGサーバ Jenkins
rsync
reporting
feedbackfix
デプロイ設定
除外
ファイル
git add
git commit
mail sendupdate
除外ファイルの前回か
らの更新差分をGitリ
ポジトリで管理し、リ
ンクURLを生成してプ
ログラマにメール送信
プログラマはメールを
受信したら業務開始前
に除外ファイルの更新
漏れを修正。デプロイ
ミスを未然に防止。
事例② 除外ファイルの更新漏れの自動通知
除外漏れ表示画面
その他
• Nativeアプリ(Android・xcode)のビルド
• 複数散在するリポジトリ間の差分チェック
• etc…
目的に応じ利用していますが、今回は割愛します
導入効果
事例① 規約チェックの自動化
• 規約違反件数が約5分の1に削減された。
• 新規のコードだけではなく、既存のコードに対
する自主的な改善が行われるようになった。
• 上記の結果として、ルールを覚えることを必要
とせず共通化されたスタイルでコーディングさ
れるようになった。
<導入効果>
事例① 規約チェックの自動化
• 運用が定着化するまで時間を要する
<課題>
いくら規約を覚えなくても良いといっても、IDE
上に表示されたWarningやErrorに従い修正を行う必
要があるため、慣れるまでに時間を要する。
VenusBaseに基づきCode Formatterを定義し修正コス
ト及び学習時間を短縮化
• 全プロジェクトに展開できていない
地道に普及活動を行う
事例② 除外ファイルの更新漏れの自動通知
• 導入を行った2013/4/7以降、除外漏れの発生が激
減。
<導入効果>
• 今月に至っては0件。
今後の展開
目指すは、テスト自動化
ではなく、
自動ビルドによる
デグレ防止
でもなく、
CIツールを核とした
開発のオートメーション化
今後の展開
• リポジトリ更新時の単体テスト自動実行
• 要修正箇所のバグチケット自動発行
• デプロイ時のコードチェック及びデグレ防止
CIを各とした開発のオートメーション化
• 各品質指標の計測
上記実現のためにまず、現在実施している施策を
全プロジェクトに展開させることからスタート
• etc…
さいごに
CROOZでは
今後の展開を一緒におこなってくれる仲間を
募集しております!
http://crooz.co.jp/recruit/
ご清聴ありがとうございました

Croozにおけるjenkins活用事例20130618