Jenkins Day Japan 2017 レポート

 

先週、Jenkinsのセミナーが開かれた。

テクマトリックス主催の、太っ腹な企画。

その内容の簡単なレポート。

発表資料は、下記サイトからダウンロードできます(入力事項あり)ので、ぜひどうぞ!


日時:11/9(木)9:30~17:00
会場:ベルサール半蔵門
内容:Jenkins Day Japan 2017

 

cloudbees.techmatrix.jp

 

 

コンテンツ:
1.組織横断的な環境でのソフトウェア開発を加速させる、段階的なCI
 (原題:Multi-Stage-CI System to speed up the SW development in a cross-organizational environment)
  Robert Martin 氏 BMW Car IT GmbH SW Project Leader
2.テンプレート、Groovyを用いて、Jenkinsを”Sweet”に
  (原題:Sweeten your Jenkins with template and Groovy system)
  Harald Gottlicher 氏 Robert Bosch GmbH Software Architect
3.テストのフィードバックサイクルを早めて、変更に強いソフトウェア開発を実現
  野中 亮 テクマトリックス株式会社 システムエンジニアリング事業部
4.Jenkinsの生みの親、川口耕介氏が語る(仮題)
  川口 耕介氏  CloudBees, Inc. Chief Technology Officer

 

[全体の感想]
BMWの事例は、大規模でかつ数億行というソースコードをHW込みでテストする環境をCI化しているというすごい事例だった。
その際には、ひとつのジョブの単位の設計をしっかりやらないと、HWのテストまでどういうパイプラインで流れていくようにするかという目的を達成できなくなる。
ジョブの単位の設計はしっかりしないと、結局は手動と同じという結果になりかねない。
Jenkinsの利用により、技術的負債を増やさずに価値をすばやく判断し、ビジネスの創造に時間をかけていかなければならない、という川口氏の講演には、日本と欧米の意識の違いが大きく出ているなぁと感じた。

いや、もうすでにやっている会社さんも多くなってきたが、日本のスタンダードということにはまだなっていない感覚を持っています。

川口さんは、危機感を持ってください、ともおっしゃっていたので、その感覚もあまり間違っていないのかもしれない。

 


[概要]
1.組織横断的な環境でのソフトウェア開発を加速させる、段階的なCI
 ・BMWのHWを含めた開発で行っているCIがどう行われているか、という内容。

  大規模プロジェクトでのCIは、多段階のCIシステムにする必要がある。
  SWアーキテクチャから考えるのが大切。
  部門ごとに分けられた内容を考えるのではなくて、機能ごとに分けられているチームを考え、CIを設計する。
  最初からリリースまで、どのくらい時間がかかるかを測った。
  1人の人のたった一行のコード変更が反映されてリリースするまで、5週間かかる。
  一つのものをリリースするのに、こんなに時間がかかっていたら、担当者はやっていたことを忘れてしまう。
  CIでは、誰かがこけたら(Failしたら)次にいけないようにしている。
  自動化されていない手動の作業は、ソースコードの修正だけ、という状況にしている。
  HWのテストまでを30分以内でやらなければいけないとわかっている。
  これよりもかかるようであれば、さらに細分化する必要があると考える。

 

 ・夜間ビルドとCIの違い
  CIシステムを導入したら、Failがある場合は、必ず次に行ってはいけない。
  働き方の時間を見ながら、何分以内でCIを回す必要があるのかをちゃんと考える必要がある。
  夜間ビルドの場合は、失敗がまとめて報告されるので、切り分けが困難だったりする。ところが、失敗したら次に行かないというCIがあれば、失敗の修正と回復は最小限の時間ですむようになる。依存関係の少ないアーキテクチャを目指すべきである。
  協力会社、自社内での関係等、SWのアーキテクチャや契約もみていかないといけない。
  多段階CIシステムには、専門のCIチームを用意する用意がある。
 
 ・早い開発が何で必要になるのか。
  変更に強い、費用対効果がある(時間を削減=自由な時間ができる)、そういったことをチームで議論し続ける必要がある。


2.テンプレート、Groovyを用いて、Jenkinsを”Sweet”に
 ・テンプレートで特有のUIを作ることができる。
  いろんな商品・製品を扱っている。
  開発者でない人たちもいる。そういった人たちが意識しなくても、勝手に背後で動いている、そういうCIでなくてはいけない。
  Jenkinsを知らないひとたちでも使えるシステムを提供できる。
  ビルドを自動化するのは当たり前だが、例えば、jobをつくるなどのjenkinsの機能も自動化する。
  以下のようなテンプレートをGroovyで作成すると、管理者も楽になる。
  -マルチブランチパイプライン
  -フリースタイルジョブ
  JenkinsFile(groovyで記述)も、変更したらGitで管理する。プロジェクトマネージャがテンプレートファイルを複製してプロジェクトに提供する。
  パイプライン自体が「モノリシック」になってしまうこともあるので、注意が必要。

 

 

3.テストのフィードバックサイクルを早めて、変更に強いソフトウェア開発を実現
 ・変更があるごとにビルドなどのジョブをしかけることで、負債の蓄積も最小にすることができる。
 ・ビルド~テストを仕掛ける単位はなるべく影響範囲が小さいうちに実施したほうが良い。
 ・テスト自動化する象限は第4象限がよい。⇒実践アジャイルテスト
 ・変更を割り振っていって実行を適切に行うもの⇒jenkins


4.Jenkinsの生みの親、川口耕介氏が語る(仮題)
 ・Jenkinsの生い立ち~成長期
  生物と同じで、カンブリア爆発があり、多様性が起こった。進化そのものは徐々に起こる。
  Jenkinsへアップデートセンターを作ったので、プラグインの作成をするコミュニティがどんどん出てきて、利用が爆発的に広がった。

 ・Jenkinsの恐竜期
  昔、ツール整備する人は職人気質。自動化はチーム内でやる作業だった。
  プラグインを組み上げて自分のCICDを作っていた。そこを、ある程度標準な組み合わせを最初に用意する。
  なれて、変化点が見えてきたら自分たちの使い方に合わせた環境を作れるようなプラットフォームにしておく。合わせてドキュメンテーションをしっかり整える必要がある。

 ・現在~未来
  ビルド職人がやるという時代は終わった。ビジネス価値を早く届ける必要がある。
  実験と反復を早くやる必要がある。自動化職人はチームに所属しない。組織としての専門チームで存在しているべき。
  痛みを伴ったデジタルトランスメーションをすることで、中央に生産性向上の専門チームができることが多い。そのチームが会社の開発プロセスを決めていく。
  ビジネス価値の創造にフォーカスしていけるか、が大切である。生産性を上げることで変化に強くなる。すぐに結果などを得られるようになるからである。大規模な会社ではこういった取り組みが必要である。

 ・これからのCIのあるべき姿
  継続的デリバリーをする、そこからビジネス価値を創造する方向へどう行けばいいのか。自動化だけにフォーカスせず、一歩下がって開発全体を見なければいけない。
  パイプラインを作った一つの理由として、視野を広げやすくなることが挙げられる。一歩下がって開発全体を見て、組織を見て、ビジネスを見る。これがこれからに必要となることだ。