第7回Jenkins勉強会に参加してきました。今回のテーマは組み込み系のため普段とは違った内容だったかと思います。
発表スライドは第7回Jenkins勉強会から順次リンクを張っていきます。動画は後程アップロードされるはず。
キヤノンの馬場さんの事例はよく見ておくべきかなあと、自分を含めだれとなく。
川口さんが最近作成した Database Plugin, Recipe Plugin, Remote Terminal Access Plugin の紹介。
Jenkins は XML をファイルシステムに書きだすことで設定やビルド結果を保存しているが、大規模に使うにはファイルシステム上の XML はスケーラブルではない。そこで Database Plugin というライブラリ用のプラグインを用意し、他のプラグインがデータベースを簡単に扱えるようにした。Jenkins 全体用およびプロジェクト毎用のデータソースを DI で注入してくれるので、プラグインから簡単にデータベースを使えるようになる。JPA にも対応している。
Jenkins を使おうとするユーザからよく出てくる課題として、何にどう使っていいか分からないというのがある。そこで Recipe Plugin でジョブ設定をエクスポートしてレポジトリに登録できるようにし、別の人がそれをインポートできるようにした。ジョブが必要とするプラグインがある場合にはそれらをインストールさせることもできる。
ローカル環境ではビルドやテストに成功するが Jenkins に載せて実行すると成功しなくなるという話もよくある。Remote Terminal Access Plugin を使うと、ジョブを実行するのと同じ環境で SSH ログインできるようになり原因究明をすることができる。ブラウザでターミナルエミュレーションをすることもできるので別々のブラウザでターミナルの共有もできる。
Q. アーティファクトを保存すると Jenkins のホームディレクトリのサイズが大きくなってバックアップを取れなくなる。データベースに格納できないか。
A. データベースが最適かは別として、アーティファクトの保存方法を抽象化して単にファイルで保存する以外の方法を検討したいと思っている。現状でも Artifactory Plugin のようにレポジトリに登録するものがある。
テクマトリックス社の天久さんがお客さん先での Jenkins の導入や環境構築の例をだし、組み込み系は事例が少ないけれども Java などでのエンタープライズ系などと大差なく使えるという発表。
単体テストの支援ツール開発や Jenkins 導入・環境構築を行っている。Jenkins の運用は行ってはいない。お客さんからよくある声としてエンタープライズ系の Jenkins の事例はあるが組み込み系でも使えるのかということをよく聞かれる。
組み込み系であっても Java での使い方と大差がなく、ソースコードレポジトリからチェックアウトしてビルドやテストをしているだけなので同じように使うことができる。あえて組み込みっぽいことといえば、分散ビルドでクロスコンパイルを行うとか、単体テストがシミュレータやホスト環境で行われる程度のことで Jenkins の構築方法はほとんど変わらない。
まだやっていないこととしては、シミュレータではなく実機での単体テスト自動化やコードレビューである。
Q. Android や iOS の事例は割と聞くがそれ以外は。
A. 特に Android は開発環境が進んでいる。他は進んでいないのが現状で、まだまだこれから。
キヤノンの共通技術部門主導による Jenkins 導入の事例紹介。Jenkins はボトムアップで使われていくことの多いと認識しているが、トップダウンで大規模に展開していった貴重な事例の紹介。
品質向上のためのテスト自動化でCIツールを選定し2010年後半に旧Hudsonに決定した。2011年には専攻チームを立ち上げてプラグインの内製を始めた。2012年は各事業部への展開を推進している。
Jenkins の構成としては、アクセス制御の柔軟性のためチームごとにマスターノードを用意しているようにしている。マスターでのビルドは禁止にしている。スレーブの追加で簡単にビルド環境を追加できるようにするためで、マスターのマシンでビルドを走らせたいときにはマスターのマシンをスレーブとして追加する。最近よくある構成としては一台のマシンに複数のマスターを動かして、代わりにスレーブに沢山の台数を用意している。標準設定とプラグイン込のテンプレートを使うことで1分で展開ができる。
Summary Report プラグインを内製している。各種メトリクスを統合してレポートするプラグインである。これにより多数あるチームのビルド状況を一括で取れるようになっている。
チームごとの統計を見てみると、熟練具合のばらつきが大きい(スライドの12ページ以降に具体的な数値やコメントがあるのでそっちを参照)。アーティファクトの受け渡しのためにカスタムワークスペースを悪用していたりしていてクリーンビルドが実現できているか怪しいチームもある。
継続的インテグレーションだと意味が伝わらないので「継続的テスト」と呼んで導入させようとしている。また「テストセカンド」というスローガンを掲げている。テストファーストではなくてもよいが、最後の最後でテストをするテストラストではダメだと意味。
Q. Jenkins の展開方法は。
A. 標準設定とプラグインインストールを済ませた Jenkins を rsync で CentOS にコピーし、ポート番号などをスクリプトで設定している。
Q. プラグインはいつ公開するか。 (川口さん)
A. 委託で作って1000万かかっているので寄贈すると損金扱いになってしまう。
Q. コピーライトはキヤノンもちのままでもいいので、皆が使えるようにライセンスを変えてくれるだけでもいい。 (川口さん)
Eclipse CDT のプロジェクトをヘッドレスでビルドする事例の紹介。Maven や Make のファイルを用意してビルドするのではなく Eclipse CDT プロジェクトをそのままビルドできる。「ビルドツールは？」「Eclipseです」という受け答えをすると鼻で笑われていたのだけれども、この発表のやり方ならば Eclipse も立派なビルドツールだろう。
C++ で開発をしている。Jenkins を導入する前はビルド作業が複数人による手作業で、バイナリの持ち回りがあるために1日かかっていた。GUI を使ったビルドであったため自動化ができていなかった。
自動化をしたいが Java なら Ant や Maven があり、C++ なら Makefile だろうが、わざわざ Jenkins のために Makefile を用意するのは面倒だったため Eclipse CDT のプロジェクトを Eclipse にビルドさせることにした。あまり知られていないが Eclipse でのビルドをコマンドラインから実行することができる(使い方はスライド35-38ページ参照)。
今後は Raspberry Pi による XFD に挑戦したい。「コンピュータは作業を、人はクリエイティブな活動を」
Q. Eclipse をフックして情報を取れないか。たとえば Eclipse ならばバイナリの出力先を知っているはずで、その出力先のファイルを Jenkins が自動的にアーティファクト化するなどの活用ができないだろうか。 (川口さん)
A. 不明。