Jenkins Day Japan 感想 #Jenkins

昨日、Jenkins Day Japanに行ってきたので、感想を書きたいと思います。

※あくまでも個人の感想です。

会場の感想

豪華なホール（ベルサール半蔵門）、万世のカツサンド＋お茶が出るって素晴らしい。
- （参加無料 のイベントです）
- テクマトリックス社さんに感謝!!
反面、ちょっと会場が明るすぎてスライドが暗く見えてしまって残念だったなあと思いました。

組織横断的な環境でのソフトウェア開発を加速させる、段階的なCI (Multi-Stage-CI system to speed up the SW development in a cross-organizational environment)

車に十数個搭載されているECUの、複数人、複数チーム、複数組織についてのCIアプローチを述べたもの。
- 1つの車にC/C++/Matlab などのコードが100万行以上ある
それぞれのECUの中でアーキテクチャがレイヤー化されており、レイヤーごとでの各コンポーネントの開発とともに、その後、コンポーネントを垂直統合してテストするなど必要。
Multi-Stage といっているのは、下記のような各段階ごとに統合していくことを言っている。
- 最終製品(ECU) ← 製品として統合 ← 組織として統合 ← … ← コンポーネントとして垂直統合 ← チーム ← 開発者
段階によってやることが違う
- 開発者のコミット後、チーム(Team CI) では各種チェック・単体テスト・統合テストを実施する
  - ローカルマシンでライセンス上実行出来ないチェックもCIでは実行できるなど
- 最終的な段階ではアーティファクトリポジトリにバイナリを収めておいて、ソースからのビルドはない、など
なるべく早期にエラーは見つけるようにする
- 開発者コミット後、短いインターバルタイミングでTeam CIを開始し高速フィードバック。
各段階でエラーがなければ自動的にソースはマージされて次の段階へ行く
- 開発者がコミットさえすれば、後は全部自動で動く
当然こういうことをするためにアーキテクチャの整備は必要
デリバリーパイプラインと組織は紐付けない
特定のソースコード変更が製品反映まで 3-5 weeks かかっていたのを 2-12 hoursに短縮できそう
CIへの投資は継続的に必要です
このCIの原則従おう: https://martinfowler.com/articles/continuousIntegration.html

大規模なソフトウェアを統合するアプローチとして真っ当な解だと思いました。

結局、JavaのOSSなどを含めたソフトウェア開発を切り取ってみても、最終的には上部のようなことを全世界で、見ず知らずの人達同士でやっているんじゃないでしょうか？

各開発者がGithubなどにコミット
CIでチェック＆ビルド
1. OKならMaven Centralなどにリリース
2. 大規模なものなら、垂直統合のテストなどを経てリリース
他組織がMaven Centralから複数種のアーティファクトを取得して統合。

フィードバックサイクルの短さもよく強調されていました。これはそもそもこのイベント全体を通して語られていたテーマの一つのような気がします。

SWEET TIMES IN JENKINS (SWEET TIMES IN JENKINS strategies for managing large projects with Pipeline, Groovy, plugins and templates in Jenkins)

非開発者に向けて、ハイコンテキストなパラメタライズドされたビルドジョブの塊をJenkins上で制約つきで動かせるようにするいろんなやり方の紹介
- 要するに Domain-Specific Jenkins という話です。
- Jenkins Enterprise が便利ということを知りました
大きなJenkinsは作るな。Jenkinsは分けられる単位で分けよう。

非開発者というか、開発者であっても、Jenkinsが複雑で難しくなることはよくあります。

ボタン一個押せばCIが終わるというのは理想の話でして、そもそもそういうシンプルな用途じゃないからJenkinsを使っているということも十分にあります。

ただ、いろいろJenkins上で解を探すなら、Jenkinsの外でSPAとかElectronとかガワをかぶせてダッシュボードとか作れば？と思ったけど、やりたいことに対して開発難易度が高いのと、カスタマイズさせたいビルドジョブの量も大量すぎるという点で、あまりそういう発想になれないのかなあと感じました。

最後らへんはトイレに行きたすぎて集中できませんでした（反省）。チョコレートごちそうさまでした。

テストのフィードバックサイクルを早めて、変更に強いソフトウェア開発を実現

Jenkinsの本来の価値や用途を見直そうよ
- 現場でよくあるCIのアンチパターンになってないか？
CIのフィードバックの短さは正義
- フィードバックしようよ
コミットごとでエラー拾おうよ
静的解析だけじゃなく単体テストもしようよ

個人的にな感想ですが、Jenkinsに純粋なCIエンジンとしての役割の期待はされていないと思っています。

しかし一方で、よくありがちな、開発現場の妥協でCIのあるべき姿が歪められているのは、決して好ましい状態ではありません。

日本の開発事情に沿ったCIの改善提案が今後必要なのかもしれません。

Jenkinsの生みの親、川口耕介氏が語る

Jenkinsの寂しい初期、そして一気に花開いたカオスな黎明期に至るまでを紹介。
- そして今、Jenkinsはプラグインの多様さを誇る時代は過ぎ、構成の安定・ベストプラクティスを構築する時期になっている
  - Pipeline (Jenkinsfile), Jenkins 2.0 ...
CloudBeesの提供するJenkinsはターンキーで使えるベストプラクティスが実践できるJenkins
- プラグインのアップグレードは確かに恐ろしい結果を産むケースがありました。（体験済み）
- 一般的に落としてはいけないJenkinsについては、テスト用Jenkinsを使って、アップグレードを試験してから、移行するのがお決まりですが、それをクラウドサービス側である程度やってくれるなら非常に楽な話ですね。（OSSコミュニティが出すFedoraとRedHatの関係のようなものと言っていました）
- JenkinsのUI改善は、ずっと課題感を感じているが、OSSコミュニティだけではUIの改善は難しかった。
  - e.g. Jenkinsfile をJenkins上の専用エディタで編集して、そのままそれをリポジトリに反映
ビジネス戦略としてCI
- チームのビルド職人という「有志」がJenkinsを立ち上げる時代は終わりを迎えている
  - ローカルCIからグローバルCIへ
- ビジネス戦略としてCIを取り入れて、要求→実装→リリース→フィードバックのサイクルを極力短くすることが必要
- ビルド職人が野良Jenkinsを作るのは、もはや価値を創造しないので、クラウドサービスを活用したほうがいい（というように聞こえた）
PayPalの事例
- 2013年 1つJenkinsに4万ジョブ →　2014年 2500以上のJenkins → 2015年 Apache MesosでJenkins → 2016年 Docker → 2017年 BlueOcean (CloudBees)
- DX (Developer Experience) チームがあり、そこがPayPalのCIなども含めて改善している
DevOptics
- 近視眼的に開発を捉えるのではなく（各役割に閉じこもるのではなく）、自分の活動がJenkinsを通じてどういう価値創造を産んだのか見られたりすることで、insights を産むといいなあという構想？

Jenkinsの役割の転換期、CIの扱われ方の変化（戦術から戦略へ）、未来への構想といった非常に興味深い話でした。

どちらかというと僕のようなビルド職人よりは、経営に近い、戦略を決定する人に向けたメッセージですね。

DX(Developer Experience)という言葉はいいですね。お気に入りになりました。

ただ、身の回りのJenkinsの利用事例を見ると採用動機が OSS/On-Premises/何でもできるというのが強かったりします。まあそうすると野良Jenkinsの誕生ということになるでしょうね。

このままでは日本はもっと遅れてしまうという川口氏の危機感はもっともで、ビジネスでの価値創造を真剣に考える時代なんだなあと思いました。

最後に川口氏が触れたDevOpticsについてですが、個人的には変更起因などのいろんな情報が紐付いた CHANGELOG.md 的なものがメタデータとしてビルドアーティファクトにくっついたりして、社内だけではなく、組織を横断すると技術的には面白いのかなあと思いました。

総合して

CIやJenkinsについて、いろいろなinsightを深められたと思います。
ニーズとして、具体的なビルド手法を学びたかったという人が多かったように思えます。そういう人には、ユーザコミュニティ主催のイベントの方が適しているのでしょう。