読者です 読者をやめる 読者になる 読者になる

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
Redmineと連携して設定のレビュー

ラウンドテーブルで挙がった「Jenkins設定が属人化されて1人しか触れない」問題に対しては、Redmine Code Review プラグイン( http://www.r-labs.org/projects/r-labs/wiki/Code_Review )を利用して、情報共有を行っています。

レビューチケット例 

f:id:sgtech:20160926170950p:plain

この場合の設定のレビューは、xmlファイルを比較したり確認したりする事になるので視認性は悪いですが、ある程度Jenkinsの管理に慣れてさえいれば、設定を差分で確認できる事の方がメリットが大きいです。

また、先の通りJenkins設定がバージョン管理されているので、レビューを回された当人の手元で該当バージョンの環境を再現する事もできます。

結果

このJenkins設定のバージョン管理とレビューの仕組みは、うちのチームに社内Jenkins環境サポート人員が1人増えて2人になったタイミングで導入しました。

該当プロジェクトのJenkins設定を把握してもらうのに、非常に効果的に働きました。

1人でJenkins設定の面倒を見ている場合でも、年単位で運用していると設定変更の経緯を忘れている事も多いので、本当にこれはやっておく価値があると思います。

最新の Jenkins 2 ではまた違ったアプローチも考えられますが、今日はここまで。

 

まとめ

という事で、CEDEC2016のフォローアップ記事+ちょっと突っ込んだ内容という形で、社内で実際に運用しているJenkins環境を2つ紹介しながら色々書いてみました!

 

ゲーム開発を支える技術ということでゲーム開発の技術そのものでは無いためちょっと興味から遠い方も多かったかもしれませんが、毎回執筆者も内容も変わる予定ですので次回をお楽しみにお待ちください!

Powered by はてなブログ