sgykfjsm.github.com

第7回Jenkins勉強会に参加した

概要(http://connpass.com/event/1690/ からコピペ)

Jenkins勉強会も回を重ね、ついに7回目となりました。今回は、これまであまり事例が出てこなかった組み込み系、もしくはC/C++のプロジェクトでJenkinsを利用している方からの発表を中心にお送りいたします。 日時:2013年1月28日(月) 19:00-21:00 場所:オラクル青山センター ハッシュタグ:#jenkinsstudy

togetter: http://togetter.com/li/446487

今回は組み込み系とのことで、自分はWeb系の人間だけれども、今後の参考とするべく参加した。 業界は違えど、Jenkinsで品質を改善していくことに違いはないと思ったので。

以下、メモ書き。

「最近作っているプラグインの紹介:レシピプラグイン、リモートターミナルプラグイン、データベースプラグイン」

  • 川口さん
  • DBプラグイン
    • すべてをXMLに保存するのは無理がある。とのことが多かった。
      • テストデータの保存
      • 成果物が500MB超えるとJenkinsのBackupが取れなくなる
      • 高機能クーロンとして分刻みで起動するジョブを数千レベルで使うとIノードを食いつぶしてしまう。 TODO: 下の2つについてはよくわからなかったので要調査
    • テストデータの保存とか
      • XMLでなくなることで起動・クエリ速度の工場
      • 大規模インスタンスへの対応
    • インフラとしてコアでDBを提供するようにした。
      • Jenkins全体用
      • プロジェクト毎用 このへんは実際のコードを少し見せてくれて説明していた。
    • JPA2サポート
      • DBを利用するプラグインへの部品提供
        • 2つほど機能名?がスライドにあったが、メモれず…。
    • 施策として標準UIの提供を行った。
  • レシピ・プラグイン(凄い)
    • ユーザ:プラグインを使ってみたいけど、使い方がわからない。
    • 開発者:使って欲しいのでデモを提供したい (ここで実際にデモが行われた)
    • エクスポートするレシピはコミュニティサーバに公開することも可能。
    • インポートする側はエクスポートされたデータにプラグインの情報が含まれているので、あまり細かいことは気にしなくて良さそう。とりあえず使ってみるか、という事に対して敷居が下がる。
  • ターミナル・プラグイン(ヤバイ)
    • JenkinsでこけるジョブをJenkins上でデバッグできるようにするためのターミナルエミュレータ
    • GUI上でターミナル画面が出てくる。
    • SSHでのアクセスもできる。
    • 原因究明をより直接的に行えるようになる。

「組み込み業界よくあるJenkins環境構築例」

  • 天久さん
  • 結論からいうと、組込み業界だから特別な何かがあるわけではなく、環境や構成としては一般的なものが多い(主観)。
  • 最近、組込み業界ではJenkinsに関する問い合わせが増えてきている。
  • というのも、ググっても組込み業界の事例が少ないし、エンタープライズ系の話ばかり。
  • 組込み業界っぽいところとしては、クロスコンパイルにJenkinsを使う。
  • ビルド・静的テスト・単体テストまでは自動化(ビルドパイプライン)しておいて、ブランチのマージは手動でやることが多い。
  • 開発拠点が複数にまたがる場合はクラウド上にJenkinsを構築することもある。
  • まだやってないこととしては、Jenkinsから実機での単体テスト自動化とソースコードレビュー
    • 実機は準備が大変
    • 何千というケースを行うには期待するパフォーマンスが出ない
      • モバイルではAndroidのデバイスをつなげての自動化が進んでいる模様
    • ユーザのニーズ

「キヤノンにおけるJenkins状況」

  • 馬場さん
  • Jenkins導入の経緯
    • 品質向上・テスト自動化は大きな課題
    • CIツールとしてJenkinsの導入
    • 社内でデモサイトを作ったり、セミナーを実施したり。
  • 開発部隊のテーマ・チームは大小様々で、中身も色々。
  • C/C++が大半。環境ツールは標準化。でも…
  • Jenkinsの全体構成
    • チームごとにマスターを分散
      • セキュリティや使い勝手を優先させるため。
    • 同一マシンでマスター/スレイブが同居
      • マスターでのビルドは禁止!!
    • 同一マシンで複数のマスター
      • スレイブの台数を稼ぐため。
        • とりあえずやってみようという取り組み
    • 細かい構成の調整はこれから。
  • Summary Reportプラグインを内製した。
    • ビルド結果のサマリーのみをレポート
    • 履歴レポート
    • ダッシュボード ← これが内製化の大きな理由
  • 各チームのJenkninsからビルド情報をREST APIで取得
    • グラフ表示など(ジョブ数、ビルド数、不可とか、コードカバレッジとか)
    • でもデータがとれていなかったり、ジョブの粒度がマチマチだったり
    • チームを横断して、様々な指標・数値を一覧にしてレポーティングできるようにしている。
    • あるチームを取り出して、推移グラフを見たりしている。
    • データを収集して、特異な状況での原因究明に役立てている。
  • 全体傾向
    • チームでのばらつきは多いが、概ね有効に活動できている。
    • Jenkinsでの手動ビルドも人気(テスト対象が多いので)
    • 関係各社とのジョブ共有も徐々に進展
    • 一部チームは苦戦している。
      • 改善しつつある。
  • 問題
    • カスタムワークスペース利用が結構多い(同じ場所で異なるビルド)
      • クリーンビルドが確保できていないかもしれない。
    • 沢山ビルド、でも結果をちゃんと見ていない。
    • ツールが活用できていなかったり。
  • ゴール=「継続的テスト」
    • 現実的には「テストセカンド」
      • 本当はファーストだけど、最悪テストラストにはならないで欲しいという思い。
  • Q&A
    • 事業部に展開できていないのはなんで?(話の対象は開発本部だった)
      • まだ周知できていない。事業部との仕事のやり方の違いか?でも今は導入に向けて調整中。
    • 導入前後の違いは?
      • Jenkins導入前
        • 内製のものだと情報がないので、ユーザがだんだんと使わなくなってくる。
      • Jenkins導入後
        • 情報が多く、プラグインが豊富。遊び心もある。ユーザ利用のモチベーションが高くなる。 *(3つ目を聞き逃した…)
      • Jenkinsボードは公開する?
        • 色々あるけど、ライセンス的にみんなが使えるようになると嬉しい。

「Jenkinsを使うようになったきっかけ、EclipseのC++プロジェクトを簡単にJenkinsでビルドする方法」

  • @atottoさん
  • 資料
  • 補足資料
  • きっかけ
    • ビルドが手作業
    • テストコードが無い(デバッガベース)
    • 悲惨な毎日
  • EclipseでC++
    • 依存関係は自動生成される(Makefileに記述されるらしい)
    • Headless Buildでコマンドラインビルドができる
    • Jenkinsと連携できる
    • 細かい手順等はブログを参照
  • 導入後
    • すべての手順をJenkinsに詰め込む
      • 何かあったらJenkinsに聞けば良い。ただし、手順書だよりになるかも?
  • 便利なプラグイン
  • 困ってること
    • テストの完全自動化
      • 実機ベースとかシリアル通信とか。
  • Q&A
    • Eclipse CDTとJenkinsの可能性
      • EclipseとJenkinsが対話して、Eclipseが持っている情報をJenkinsが引き出せるのでは?

まとめるのが凄い遅くなってしまった…