第6回テックヒルズ『Let’s study Jenkins～さまざまなケーススタディ～』
イベント概要
第6回目となるテックヒルズ。
今回のテーマは「ビルドやテストを行う際にミスが多発する」という属人的な課題を解決してくれる、
オープンソース継続的インテグレーションツール「Jenkins」。
ビルド、テスト、さらにはデプロイまでを自動化してくれるJenkinsは開発プロジェクトにおける優秀なパートナーです。
しかし、革新的なツールであるJenkinsのナレッジは、ほとんどオンラインで得ることが出来ません。
そこで、今回のテックヒルズでは、現在Jenkinsを活用している企業に、導入の過程とその後の課題、
構築及び運用により培ったケーススタディやノウハウ、またその他Jenkinsの付加価値について余すことなくご紹介いただきます。
所感
技術的な面であまり有用な情報はなかったが、社外の取り組み方を知れてよかった。
参加者は700名程度だが、若手、私服（≠オフィスカジュアル）の人が多かった。
Web屋さんやアプリ屋さんが多かったよう。（主催会社がゲームアプリ開発会社のため？）
全体的に会社のバックアップが非常に大きいのが印象的。
CI環境構築のために内作ツールやフレームワークを導入していたりと、
会社全体で問題解決に取り組んでいる点が非常にうらやましい。
（テスト管理ツールやプロジェクト進捗可視化ツールを単独で作成するのは困難）
紹介されていたプラグインetc
Github pull request builder plugin
PHP_CodeSniffer ※Jenkinsのプラグインではない
gitlist ※Jenkinsのプラグインではない
進行中の開発プロジェクトで増えていくテストを自動で回し続けるために行ったいくつかのこと
株式会社Aiming 黒木 慎介
進行中の開発中のプロジェクトで利用。
プロジェクト開発期間は８ヶ月 初期は2人、最終的には10人の開発プロジェクト（企画、デザイナーは除く）
主にテストフェーズに利用
何を解決したかったかというと、増えすぎたテスト件数と実行時間との戦い。
問題点
テスト７０００件越え 実行時間１時間越えに →自動テストの重要性が増す。
対策
ジョブ分割・Jenkinsの並列実行
スレーブを２台から６台に増設
テストをカテゴリ別に分割して実行
分割に便利なもの１ ラベル付け
ノードの設定画面でラベルを設定。
ラベル式をで「実行するノードの制限」
分割に便利なもの２ join Plugin
Aが成功したらBとCを実行して、両方成功したらDを実行する
最後にメトリクス計測とか。
ジョイントリガー
分割に便利なもの３ビルドパイプラインプラグイン
ビジュアル的にパイプラインが表示できるので、親子関係がわかりやすい。
Gerritを利用してレビュー
ある変更がレビューを通してどのように変更されたか。
Gerrit Trigger プラグイン
レビュー依頼が提出されたら、Jnekninsのジョブを実行
レビューの対象は全て。
そのため、実行が開発のペースに追いつかない。
差分テストが終了しないうちに修正や再提出が行われてしまう。
→Jenkins（リグレッションテスト）の完了を待たずにマージしてしまうことに。。。
原因
開発人数が増え、ペースが上がっていた。
解決したいこと
無駄な実行をしたくない。無駄なテストはJenkinsを中断したい。（失敗ではダメ）
対応策
成功（青ランプ） >exit 0 失敗（赤ランプ） >exit 1 中断（灰色ランプ） Webから止める。curlで叩いてSleepする
Jenkinsを利用するときの心構え
１ 自由度が高い
Jenkinsがやってくれるのは自動化だけ。
自動化する処理は自前だよー。
２ プラグインのドキュメントはちゃんと読もう
wikiに乗っている
それでも挙動がわからない場合は。。。GitHubのソースコードでも読め。
AimingでのJenkinsの利用
ビルド テスト実行 デプロイ サーバ再起動 データチェック （ゲーム会社なので、定期的にする必要がある、） 結果の通知はスカイプとか、パトランプなど。
利用方法の一例
企画の人が作成したマスターデータを取り込んでデプロイすると... データにミスがあるとデプロイがとまって困る。 取り込み部分だけをジョブ化。 ミスがあっても自動でわかる。
Jenkins + GitHub
株式会社ミクシィ 大塚 弘記
視聴していないので、資料のリンクのみ
検索基盤開発の為の結合テスト環境の自動化
楽天株式会社 荻野 恒太郎
Jenkinsを含めて、結合テスト環境の自動化を行った。
利用期間は半年間。
結合テストを自動化した背景
開発で困難なポイント→ コンポーネントの結合が一番困難。
それぞれのコンポーネントの開発担当者はI/Fに仮説を持って開発を進めている。
コンポーネントの結合 = 仮説の検証
開発期間の割合を見ると開発５０％、結合３０％、QAテスト２０％で結合部分が大きく割合を占めていた。
ローカルでのソースコードの変更
単体テストの追加
↓
ソースコードのマージ
テストの実行、変更のコミット
↓
コミットビルド（ビルド＆自動テスト）
自動デプロイ
↓
二次ビルド（結合テストの自動化）
大規模な結合テストを毎日実行するためには、自動化が必要。
結合テスト自動化の課題と解決策
複雑さの解決
テストの基本にのっとり品質を積み上げる。
複雑な内部状態のテストはUT・CTで。
実装コストの解決
テストフレームワークを開発することで工数削減。
シナリオベースでテストケースを表現。
仕様変更に対しての保守性もアップする（テストケースの変更も容易になるため）
JSON形式でのテストシナリオを作成(内作ツール：Ngauto)
実行時間の解決
コミットビルドで１０分程度ののSmokeTestをすることで簡易テストを実施。
スモークテストに合格したものだけが結合テストに行く。
結合テストのジョブで１時間を超えるものは分割して並列実行。
５０台のテスト環境で平行実行。
スモークテストの注意
実行時間とカバレッジのバランスが大事
実行時間は１０分程度じゃないと開発者がおっくうようになる。
ドキュメントの登録/削除
日本語処理も行う
平行性などをチェックする
複数のExecutorを配置し、並列にテストジョブを実行
Priority Sorter Pluginにてjobの優先度を設定、主要なテストから実施。
結果の再現性の確保
＃これはただ単に環境の構築方法がダメなだけな気がする。。。
テスト実施時の環境の差異がでてくる。（連続したテスト実行のためのシステムの状態に差異）
ex. 他のテストでできたデーモンが残っている、他のテストがI/O異常を起こしたまま回っているetc...
解決方法→クリーンアップ＋インストール
実際に運用している開発プロセス
システムテストのみが手動テスト。
結合テストまでをCI。
結合テストに成功したビルドバージョンをjsonに記載するのがJenkinsのデプロイゴール。
CIの効果
結合テストのバグを開発当初から見つけることで、開発コストの軽減できた。
初期に障害を潰せるので、QA期間はサービスの高度な付加価値部分のテストに集中できた。
スモークテストでは６％のバグを発見できた。発見率/実行時間的に非常に効率的。
CIの効用
対象プロジェクトの寿命が長い場合は効果が大きい
開発中のコンポーネントが多いほど効果が大きい
要求・使用。設計の変更頻度が多いほど効果が大きい（仕様変更の影響度が翌日にわかる）
＃これは変更頻度が大きいほど再利用性が低くなるので一概に言えないかも。。。
まとめ
結合の検証までを自動化することで、仮説の検証を効率化をすることができた。
CROOZにおけるJenkins活用事例（仮）
クルーズ株式会社 鈴木優一
日々の開発・保守・運用でどのように業務課題を解決しているか。
プロダクト開発スタイルの提案。
CROOSのプロダクトリリーススタイル
・リリースギリギリまでトライアンドエラーを繰り返すこと。
これを実施するためには。。。
コーディングスタイルの共通化（規約の共通化レベルではなく。。。）
運用の共通化
上記を実現する自社フレームワークの構築
この社内プロセスがあるので、チーム間での人的資源の移動が容易。
課題
重要なコーディングスタイルの共通化が行われにくくなっていること。
頻繁に行われる本番へのデプロイの過程で本来不要な
ファイルが誤って更新されてしまうことが発生してしまうこと。
原因
共通化されているルールは複雑すぎる。 確かに可読性、パフォーマンスの観点から共通化は大事だが、覚えることが大変で
古株しか良くわかっていない。
事業拡大に伴い、プログラマが急造した いろいろな（会社から来た独学スタイルの）人が増えた
基本的にＰＧ性善説に則っている。 解決のための施策
ルールから外れているものを機械的に検知し、可視化する。 ・オペミスを引き起こす疑いのあるコードや設定を機械的に設定する Jenkinsのいいところ(選んだ理由)
構築がラク 各種プラグインが充実 ジョブ管理ツールとして利用できる 実装言語によらず、全社横断で利用が可能。（言語ごとにスレーブ・マスターで統括） ドキュメントが豊富
自動テスト・自動ビルドの前に、既存課題の解決が第一！！
活用事例
規約チェックの自動化 自動化および可視化 PHP_Code sniffer VenusBase（自社フレームワーク専用のコーディング規約定義リスト）
除外ファイルの更新漏れの自動通知 リモートシェル・gitlistによる除外ファイルの更新漏れの自動通知
OSSを活用したソフトウェア開発環境構築
株式会社東芝 山元 和子
山元さん所属のソフトウェア開発センターのミッション
内作ツールの作成、東芝グループの開発プロセスの改善
東芝のスコープは家電やインフラ・Webツールの開発など、組み込みシステムから
Webシステムまで、用途・規模・言語多岐にわたる。
品質確保の質を保つ為に必要なこと。
自動化
可視化（プロジェクト進捗状況の可視化によるPM作業の効率化）
設計部分はスコープによってプロセスが異なるので、定型作業が多い、
効果的な実装～テスト工程むけにツールチェーンの構築した。
ビルドチェーン構成図
構成管理ツール→ビルド管理ツール→ソースコード解析ツール→テスト管理ツール→不都合（障害）管理ツール
基本的にメール通知 定量的管理支援ツールでプロジェクト状況は管理者は確認
ビルド管理ツール： Jenkins
ソースコード解析ツール： cppCheck、C++Test、FindBugsなどの市販ツールの結果を統合するTCANA（内作）
テスト管理： 内作ツール（テストリンクみたいな）
障害管理： Redmineと内作ツール
Jnekinsの実行内容
Jenkinsで便利になったこと。
Webから実行できる、成果物もWebから。（以前は担当者がいないとビルドPCにログインもできない。。。）
バッチ処理スクリプトを書くより簡単
内作ツールでPM向けに各種ツールから以下の情報を収集・可視化している。
ツールに蓄積されたプロジェクト情報を自動収集→集計→可視化
複合メトリクスも表示
ショート・ロングスパンタスク推移
バグ発見改修状況
タスク滞留日数
テストNG結果
Jdepend解析結果
pigとJenkinsと私
株式会社サイバーエージェント 丸山 隆司
アメーバピグの開発・運用でJenkinsを利用
アメーバピグでのケーススタディ
コードの品質管理
理想的なCIのカタチ
各自のブランチでコーディング、トランクに突っ込んで、CIサーバでビルドしてIRCに告知」
１１年アサイン当時の現実
ブランチでレビューしてトランクにコミット。
デプロイ手動。
CI環境なし。
テストコード（ほぼ）無し。
改善するためにまず。。。
トランクのプロジェクトにJenkins適用
全PJ合わせて数千個のFindbug警告
どこから手を付けるのか。
改善戦略
CI環境の整備。。。コミット、フック、フィードバック
危ないバグはみんなで修正。。。面倒ごとはある程度強制力を働かせてみんなで対応
その警告本当に必要なの？。。。一部のテストコードは解析対象から除外
ある程度の割り切り。
課題
IRC開いてないと通知に気づかない。
ガイドラインに沿ったコードになっているかのチェックを自動化
バッチ制御
ピグで稼動するバッチ処理。
５７本のバッチ処理が稼動。
オンライン処理の裏側で稼動
単発の処理がほとんど（不要データの削除、ログ収集）
つぎはぎだらけのバッチ環境
cron起動SpringBatchが混在
新バッチサーバ＆＆旧バッチサーバ
運用上の問題点
ジョブの実行状況が把握しづらい
管理サーバとジョブが同一ＶＭ上で稼動（ジョブごと管理サーバが落ちる）
とりくんできたこと
スプリングバッチを捨てる
ジョブ実行用のシンプルなＦＷを開発
ＦＷに合わせてプログラムは再作成
バッチの制御はJenkinsに委譲
cronもJenkinsで実行
スケジューリング・記録
RemoteAPIでキューイングされているジョブがないか。
同一のジョブの多重実行がないか。
今後の課題
権限の問題（認証していないの無防備）
オペレーションの自動化
前提
ピグは２系統ある本番環境を毎週切り替え（２４時間稼動なので。）
次週の本番環境でテストすることができる。
事例
本番・待機系でリリース物が異なってヒヤリ
管理画面がINternetに大公開
実はサーバ死活監視していなかった。
再発防止策
手動操作の限り、ヒューマンエラーは防げない。
→自動化
Jenkinsでのモニタリングの仕組み
グーグルカレンダーと連携して実行、メール。
リソースの差分チェック サーバ間差異、本番/待機系間差異
リマインダ（月金が公休の場合、リリース曜日がずれるので警告メール送信）
今後の課題
自動化できる範囲を広げる
デプロイ・リリース
稼動系の切り替えの自動化
メンテナンス切り替えの自動化
最後にひとこと
「途中からJenkins入れるのめんどくさいから、最初からやろうぜ！！！」
