CEDEC2016プロダクションラウンドテーブルの振り返りとレガシーなJenkins環境に纏わる話

f:id:sgtech:20160926170951j:plain

こんにちは。セガゲームス開発技術部所属のこかわです。

社内ではビルドエンジニア&QAエンジニア（自称）として、開発部署やQA部署の業務がスムーズに進むためのサポートを行っています。CEDEC運営委員等、社外でも開発者向けイベントを中心に活発に活動しています。

今回はまだ開発者ブログならではの内容は薄めですが、CEDEC2016を振り返りながら、そこから繋げてセガ社内のプロダクション技術の話をしてみたいと思います。

キーワードを解説しながら要約すると、「ビルドエンジニアリング＝チームで（巨大な）アプリケーションを開発する中で最新の動くアプリケーションを安定かつ素早く作る（ビルド）仕組み」が「レガシー＝長い期間使い続ける事で古くなった、先任者が作り上げて手が出せなくなった」状況に対してどう取り組んでいくかというお話です。

CEDEC2016プロダクションラウンドテーブルの話

f:id:sgtech:20160926170952j:plain

プロダクションラウンドテーブル | 公式サイト | CEDEC 2016 | Computer Entertainment Developers Conference

CEDEC2016では、上記ラウンドテーブルの中で「レガシー開発環境をなんとかする」というテーマの担当をしました。（ラウンドテーブル記録資料：CEDiL）

CEDECでは最近プロダクション分野ができ、ゲーム開発会社内でもビルドエンジニアとしてビルド周り自動化の専任者も出てきている中で、環境のメンテナンス・自動化技術の属人化といった課題が取り上げられました。

特に自動化で業界デファクトスタンダードとして使われているJenkinsの話題は例年多く話題に挙がります。（Jenkins: https://jenkins.io/）

こかわは長い間このJenkinsに関連するプロダクション環境のサポートを社内で行ってきましたので、そこにフォーカスして話を進めます。

自身がセガ社内で扱ってきたJenkins環境

これまでに作ったJenkins環境

2008年入社から今までで、ぱっと思い出せる範囲で8インスタンス以上は本番運用されるJenkinsを立てました。1年に1Jenkinsは立てている事になりますね。

最初は、アーケードゲーム向けライブラリの自動ビルドから始まり、

　CEDEC2010 タダで始めるゲーム開発自動化のススメ

Unity製スマートフォン向けアプリの自動ビルドや自動デプロイ環境の構築がたくさんあって5つくらい、

　[Unite Japan 2013]Unity × Jenkins：一歩進んだ使い方 on Vimeo

その他1つくらい、といった感じでそこそこの回数、運用を考えながらJenkins環境を立ててきました。

ゲーム開発の自動化はプラットフォームが多様な点を軸に、言語やコンパイラなど下回りが全く異なったり、扱うデータがソースコードだけでは無い点など、いろいろやれる事が多くて楽しいです！

こういった中で、いろいろ背景や運用方法、導入時期の異なるJenkins環境を立ててきた結果、完全にレガシー状態になっているもの、レガシーにならないように気をつけて運用しているものそれぞれ存在するので、今回はそこから極端な事例をピックアップして具体的に紹介してみようかなと思います。

# ここでのレガシーは、Jenkins環境（本体バージョンや設定の属人化）に限定して話を進めます。

1. 完全にレガシー状態になっているJenkins環境

CEDEC2010 タダで始めるゲーム開発自動化のススメこの講演内の実例の環境です…。

2008年に入社後ライブラリチームに入った直後に立ててから、2016年現在まで稼働し続けています。

ライブラリ自体がレガシーになり頻繁な開発には使われなくなったものの、バグ修正依頼に対処した後の、リリース作業の自動化という点でまだ現役です。

Jenkinsバージョン：1.487

一回アップデートしようとした時に起動せず⇒元のバージョンに戻して復旧

というトラブル以降、バージョンを上げていません。

特定のプラグインでエラーが出ていたところまで特定しましたが、対応する時間を取るのを諦めてそのままになっています。

ジョブ数：163

上のCEDEC講演資料で紹介したような内容（自動ビルド、自動テスト、静的解析3種類以上、コードメトリクス計測、ドキュメント生成、パッケージリリースなど）に加えて、当時は個人のミーティングの予定などもRedmineでチケットにしていたのでそのリマインダーメールがJenkins経由で飛んでくるジョブなど、若気の至りで作ったレガシーなジョブの集合体になっています。いろいろな事を1つのJenkinsに詰め込んでプラグインも多く入っているのでこれがバージョンアップを阻害している要因でもあります。自作のJenkinsプラグインも入っています。

結論

この環境はレガシーから脱却するのを諦め、このまま最低限必要な機能を維持したまま、役割が終わるのと同時に閉じるつもりでいます。

ラウンドテーブルでも触れましたが、プロジェクトの終わりが見えている場合や今後ジョブの追加や変更など変更が予想されない場合はそのままの環境で走りきるのも手だと思います。

# もちろん、セキュリティ面やハードウェア交換、関わる人などの状況によって、きちんと対応しないといけないラインは変わると思います。

Jenkinsの設定については他のプロジェクトや今後も使えるジョブはそこだけ取り出して、新しいJenkins環境に移す事を考えた方がスムーズでした。

2. レガシーにならないように気をつけて運用しているJenkins環境

CEDEC2015 長期運営タイトルに後からパイプラインの自動化を導入した際の技術的Tips この事例でのJenkins環境を紹介したいと思います。

ここでは、自動化設定が複雑かつ長期的にメンテする可能性があったので、レガシーにならないように気をつけて運用した例です。

gitでJenkins設定の管理

ラウンドテーブルで提案した通り、Jenkinsの設定ファイルをgitでバージョン管理しています。

このやり方の最大のメリットは、設定のバックアップという意味以上に、コミット時に設定変更の意図を残せる点です。

コミットログはこんな感じです。

コミット	日時	作成者	コメント
b6d6682e	2015/01/13 14:56	粉川貴至	リファクタリング。古いJobの整理。名前修正。
c4ac6f8b	2015/01/14 16:21	粉川貴至	ビルド失敗時にビルドログをメール本文に追加
7e2c1957	2015/01/14 16:47	粉川貴至	結果通知メール微修正
9a1eb98a	2015/01/14 21:31	粉川貴至	遅延展開書き忘れ
7cdde7a4	2015/10/27 11:22	粉川貴至	#2740 コンバート時のJenkins設定ミスを修正
47e02bbd	2016/02/22 11:51	粉川貴至	#3630 タイトル機能追加に伴う自動処理追加対応

Jenkins設定を作りながらJenkins運用も進めている場合に「どのタイミングで設定をどう変えたか」をコミットログですぐに確認する事ができます。

また、運用開始後に問題や変更が起こった場合、チームのイシュートラッカーにチケットを立てから対応して、コメントにチケットIDを含めています。チームの開発の流れと同列に、振り返る必要があった時に見つけられるようにこのようにしています。

後はこれをやる時に、実際に動いているJenkins環境の JENKINS_HOME 以下を直接バージョン管理対象にしているのですが、ビルド時に作られるファイルなど設定だけを管理する上で必要の無いファイルは除外しています。

同じようにする場合の .gitignore ファイルのサンプルを置いておきますね。

.owner
jobs/*/builds/*
jobs/*/workspace/* 
jobs/*/lastStable
jobs/*/lastSuccessful
jobs/*/nextBuildNumber
logs/
war/
updates/
secrets/
fingerprints/
/*.log