Jenkins ユーザ・カンファレンス 2015 東京 2015.01.11

Jenkinsカンファレンスに参加。セッションリスト・資料

参加セッション
  • 基調講演:Jenkinsプロジェクトの現状(@kohsukekawa)
  • はてなにおける継続的デプロイメントの現状とDockerの導入(@nobuoka)
  • クックパッドにおけるJenkinsの活用(高井さん)
  • Infrastructure as a CodeにおけるJenkinsの役割(本田さん、藤原さん)
感想
  • 参加申込者数で700人を超える大きなイベント。実際集まってみると、Jenkins(や類似ツール)をどのように使ったら、それぞれの次のところにいけるかを考えている方がたくさんいることを意識。
  • 自分があまり課題と思っていなかったポイントで、他の方が課題だと思っているポイントが参考になった。課題として顕在化するかしないかは状況依存だと思うが、状況が変わっても役に立ちそう。(特にFail時にいかに通知して対応するかという話が、ここまで出てくるとは思っていなかった。)
  • JenkinsのWorkflow Pluginは、可用性の向上という意味ではとても魅力的だが、使い方を間違えないように、定義はシンプルにいきたい。
  • なぜCI,CDかというところは、今後この世界に入ってくる方にも、常に意識したい(してもらいたい)。

以下、印象に残ったポイント。

基調講演:Jenkinsプロジェクトの現状とワークフロー
  • 参加者アンケート結果
    • Jenkinsを使っていないか、半年未満という方が半数近く
  • Jenkinsプロジェクトの現状
    • DotCi、Workflow Pluginの紹介・デモ
    • Workflow Pluginでは、再起動をまたぐ長時間ビルド、中断・確認などの対話、一過性エラーに対応するチェックポイントからの処理再開、処理の再利用などサポート。
はてなにおける継続的デプロイメントの現状とDockerの導入
  • Jenkins事例
    • サービスごとにJenkinsを用意:テストの安定性、バージョンアップしやすい
    • ChefでJenkinsの環境を構築:本番と同じ環境を作る
    • Jenkinsの設定を複雑にしない:特定の人しかできない状況を作らない
    • 失敗時の通知はSlack、GitHub Enterpriseのみなので強化したい
  • Dockerコンテナ事例
    • 同じ環境を複数アプリケーションが使用するので面倒だったり問題が起こったりするのを、Dockerで解決を試みる。たとえば、ブランチ名とポート番号の対応付けが面倒なのをDocker APIで解決する
クックパッドにおけるJenkinsの活用
  • CIで守るべき価値:意図しない変更を予防できる、再現可能で自動化されている、リソースや情報を集約できる
    • 偽陽性があると、エラーを気にしなくなったり、本当のエラーを見逃してしまうので、可能な限り取り除く
    • 不具合を放置させないために、ターンアラウンドを短くし、失敗時のみメンションするなどの工夫をする
    • なぜCIするのか:継続的デリバリー、ニンベンのつく自働化
  • 結論:ふつうにしている
    • やるべきことをやる、常にそうあるようにする、の2つの意味で。