セッション内容は、「ビルドエンジニア」がどういうお仕事か、という講演でした。
専用の言葉についても優しく解説していただける講演で、とても勉強になったので講演中のメモを見ながらネットで調べた内容も含めてまとめてみます。
講演紹介
ビルドエンジニアを「専任」でやってみた ～「動けばいいや」は許しません！～
講演者
株式会社バンダイナムコスタジオ技術統括本部
技術本部 技術戦略部 コアテクノロジー1課ビルドエンジニア
篠崎 旭
ビルドチーム発足までの道
- 大きいプロジェクトがたくさんできた結果、兼任ビルドエンジニアの対応が厳しくなってきた。
- どうしても自分のメインの対応に追われて、ないがしろになりがちになる。
講演者の篠崎さん自身、自動・効率化を訴えていたらしく、社内の環境整備周り担当チームと合流してチーム発足されたそうです。
用語
-
CI（継続的インテグレーション Continuous Integration）
プログラマーのアプリケーション作成時の品質改善や納期短縮のための習慣のこと。繰り返しの手作業がなくなるほかに、ビルドの品質が安定することや、ビルドが属人化しないこと、問題の早期発見などの大きなメリットがある。
-
デプロイ
ツールやゲーム本体を配置して、利用可能な状態にすること。（目的は問わず、配置）
-
デリバリー
ツールやゲーム本体を一連の自動化で、製品提供を行うこと。（「届ける」意思をもって製品化を行う配置）
-
CD（継続的デリバリー）
リリースすればそこまでではなく、「サービス」として継続的に提供される時に必要な考えのこと。
-
Jenkins
CIを実現するためのツール。
-
QA
品質を向上する活動。
開発工程を小さい単位に区切り、それを繰り返すことでCI、CDを実現する。手法の１つがアジャイル開発。
ビルドエンジニアとは
開発者が触る開発環境を構築・運用し、自動化をはじめとした開発効率の改善を促進する。Jenkinsおじさん。ビルドの管理人。
QAとの深い関わりがあり（テスト自動化等あるから）、一括にされる場合もある。
ビルドマシンの管理を高い優先度で行うことが可能なので、障害発生時の対応がスムーズになる。
自動ビルドが止まったとしても、即時対応可能で復旧が早い。
ビルド環境の構築
ビルドパイプラインを用いて環境構築を行う
ビルドパイプラインとは...
CIを実現するソフトウェアの仕組み。
ビルドパイプラインを用い、
ビルドチェック・ツールのデプロイ・製品ROMの作成を、それぞれ自動で行う。
※必ずしも絶対に取り入れたらいい、というわけではない。小さいプロジェクトだとかえって処理の負担をかけてしまう。
実際の構成
ビルドマシン上でスクリプトを動作し、目的の処理を遂行する。
- 仮想マシン４台
- 物理マシン１２台
現実的に「人を増やす」より「ビルドマシン追加」のほうが実現しやすい。
ビルドマシンの運用/管理
-
信頼性
故障しにくさ
-
可用性
稼動率の高さ
-
保守性
メンテのしやすさ
上３点の、「信頼性・可用性・保守性」を意識する。
モニタリングツールには「ZABBIX」を使用した。
問題が起きていないかを常に監視し、一定値の負荷を超えたら対応を行う。
マシン停止時の事後対応ではなく、事前に対応を行うことで開発者の手を止めないようにしている。
- ZABBIX
サーバ、ネットワーク、アプリケーションを集中監視するための、オープンソース総合監視ソフトウェア。
バージョン管理
一見、バージョン管理とビルドは関係なさそうだが、これは切り離せない関係。
開発者がビルド対象をコミットしている以上、バージョン管理の扱いは重要になってくる。
効果的に利用するために、なんでもやるスタイル。
専任することの意義
-
設計・構築・運用をすべて見る。
兼任だと、後々「運用」がないがしろになる
-
他のプロジェクトからも注目されることを活用できる。
ビルドの噂が広がり、情報収集が捗る。
-
インフラ資産の効果的運用を行う。
システム部門に丸投げしない。収集した情報で、問題発見・解決し、効率化を進めていく
CIを高速化する
自動ビルドすることで、開発スタイルが変わった。
ローカルで頑張らず、とりあえずコミットしてビルドに任せる。
それにより、いくつかの問題が発生した。
- ビルド中の修正に依存した修正がしずらい
- ビルド待ちが発生する
待ち時間を減らす
待ち時間が発生する要因
- 大量にコミットが相次ぐ（行列待ちのイメージ）
- 単純に１ビルドにかかる時間が長い（とくにC++）
これより、CIにかかる時間（コミット〜ビルド結果通知までの時間）の短縮が必要なことが判明。
並列ビルド
別々なビルドは、複数マシンで並列に実行する。
ビルドマシンの数に比例して時間短縮するので、スケールアウト可能である。（ただし、ある程度のラインで頭打ち）
これにより、ある程度の速度改善は実現。
分散ビルド
分散ビルドツールを使用してビルドを行う。
何も考えずに早くすると、問題が隠れてしまう。
コード中のビルドを遅くしているポイントを探る必要があった。
単体のビルド時間の改善
よくある原因
- 過剰なincludeによるヘッダの肥大化
- テンプレートの特殊化
- ビルドオプション（依存関係など）
ヘッダの依存関係を可視化し、開発者に情報提供を行った
可視化はシステムやツールを通して行う
-
VCの/showIncludesオプション
C++のコンパイルオプション。インクルードファイルの一覧を表示。
/showIncludes (インクルード ファイル一覧) -
Include-What-You-Use
不要なヘッダ、include、前方宣言での置換方法を教えてくれる。
include-what-you-use/include-what-you-use -
Doxygenの依存グラフ
C++クラスの継承図の生成を行うことができる（graphvizも用いる）
Doxygen
専任することの意義
- ビルド時間を短縮するには、プロジェクトのビルドを深く知る必要がある。
- パイプラインを整備している本人だからこそ、総合的なアプローチができる。
品質向上を目指す
警告エラーへの意識改革
専任ビルドエンジニアがつくことで開発への意識改革が起こった。
「コミットで警告出たら、すぐに直す」意識が高まった。
重要な問題が修正されるまでリリースしない。
CI/CDの「継続的」って？
- 開発のイテレーションをいい循環で回すことが大事。
- いい製品は、いい開発環境の継続で作られている。
コードレビュー＆単体テスト
-
コミット前のコードレビューを義務化した。
開発者は「Perforce Swarm」というツールを使用。
Swarm 描画周りなどの困難な場合を除いては、常に単体テストも追記する。
コミットごとに自動テスト
ビルドパイプラインの中で自動テストを行う
-
単体テスト
自動で警告やエラーの数を可視化して場所を示す、独自のパーサを使用
-
スモークテスト
プログラムを動かしたところをのキャプチャを一覧で表示し、状態を確認するテスト。
問題情報の集約
深夜には、複数の解析ツールを用いて多面的に品質の分析を行う。
解析中に生じた問題は、ツールごとに通知するのではなくCoverity Platformに集約して通知する。
- Coverity Platform
それぞれのツールの解析結果をJSONでインポートして、一覧化する。
Coverity
専任することの意義
- 解析ツール同士のインテグレーションを効果的に進められる
- 問題をこまめに確認して、開発者にフィードバックをする人がいることで「問題の放置」を減らす
結論
- 大規模化した開発では、欠かせない仕事となっている。そもそも大量に仕事があるのに兼任でやるのは無理。
- 兼任で済んでいたとしても、いざ専任でやるとやれることはとても多かった。
- 「動いたからOK」よりも「効率よく作れているか」を考え、安定した環境を望もう。
まとめ（個人の所感）
継続系のサービスが増えていく中、ビルドエンジニアが専任になっていくのは、自然の流れに思えました。
効率化をあげるツールは沢山あるけど、いざ運営中のアプリ等に盛り込むのは「リスクがー」「時間がー」と、つい後回しになっているのが現状です。
かつかつなスケジュールの中でそこに専任を建てるのも難しいケースもありますが、開発効率化で良い流れになった経験が自分にもあるので、ぜひとも取り入れたい話だと感じました。
また、１つ１つの問題に対して丁寧に取り組めることで、結果的にビルドエンジニアに限らず、いま兼任で行っているジョブも「専任」で行うことで日頃くすぶっている問題が解決に導けるのではないかとも思ったセッションでした。