2018/10/16 に開催された Jenkins Day Japan 2018のイベントレポートです。

●イベントのテーマ
今年も、日本でのJenkinsを盛り上げるため、川口耕介氏をはじめJenkinsをリードするエンジニアを特別講師としてお招きし、最先端の取り組みについてご講演をしていだきます。

ソフトウェアのリリーススピードを支えるCI/CDの実現やテスト自動化を検討している方、企業の開発力と競争力の創出に役立つ内容となっております。

■大企業におけるDevSecOpsの変革

Experian / Moied Wahidさん

●DevOpsとは
・型に従う必要はなく、自分に合った形で作り上げるべき
・品質が担保されたソフトウェアを、高速に提供することが目的

●どこからDevOpsに手を付ける？
・強力なビジョンをみんなに納得してもらう
　・サイクルタイムの目標 = 1日
　・ボトルネックのビルド時間目標 = 1分
・全ての組織に仲間を作る
・テクノロジー、プロセス、チェンジマネジメントが必要
　・経営層に見えるように効果を可視化
　・定量化しないと改善できない

●DevOpsでやってきた流れ
・全社共通の仕掛けを作って、開発者が見つけられるようにした
・システムの技術スタックを固めた
・構成の変更
　・40,000ジョブ : 1 Jenkins だった
　　-> 1人 : 1 Jenkins on 1 VM
　　-> インフラから見ると、効率的ではない
　・今はDocker
　　5000 VM -> 5000 container / 100 VM
　　1日 100万コミット、570万のtest、120TBのfact をさばいている
・パイプライン
　静的解析とセットで、セキュリティスキャンも掛けている
・パッケージング
　コントロールしきれないので、できるだけ小さく
・モニタリング
　ノイズが含まれることが前提 -> 大事なシグナルを見逃さない
・使われていないソースを取り除くのも大切！

●パイプライン
・コード管理は、トレーサビリティの確保が大切
・ブランチ戦略は、簡単なgithub flowで十分回る
・ビルド/UT/FTで、高速なフィードバックループをつくる
・テスト環境の方針は色々あるけど、数が多いので共有方式で構築した
　※2900サービス、120億エンドポイント

●開発生産性は終わりなき旅
・自前でもマネージドでもPaaSが必要
・企業レベルで継続的デリバリの文化
・パイプラインの要所要所にゲートを用意
・self-healingには、各種のモニタリングが必須
　レイテンシ、トラフィック、障害割合、リソースの利用状況...

●Developer Data Platform
・あらゆるプロセスをモニタリングして
　プロセスの変更が、どんな効果を生んだかを見える様にする
・どこで落ちたかが明白 = どこを直せば良いかが明白
・200人で障害調査 vs 1チームで障害調査
・チェスの戦略/戦術を考えるような活動になる

●Engineering Excellence
・Waterfall -> SAFe
・4半期リリース -> 隔週リリース
・手動テスト -> 自動テスト
・Dev & Ops -> DevOps, SRE
・計画停止 -> ゼロダウンタイム
・オンプレ -> Public Cloud

●学び
・DevOpsは大変。へこたれない楽観主義が大切
・みんなを楽にするチームこそ、優秀なエンジニアが必要
・Infrastracture as CodeもCIで
・顧客=開発者と考えた、顧客第一主義
・アンテナ / 視野を広げ続ける
・やっていること、成功体験をみんなと共有

●Q&A
・勉強会/情報共有はどれくらいの頻度で実施する？
　隔週くらい。SharedServiceチームからの情報発信が
　どれくらい顧客（開発者）にリーチしているかは計測している。
　目的、状況を共有して、仲間だという共通認識をつくる。

■こうしてDevOpsは大人になっていく 初期導入の後、DevOps の取り組みをどのように拡大するか

ABN AMRO Bank N.V. / Stefan Simenonさん

●2015年
・抱えていた課題
　リードタイムが長い
　官僚主義的なプロセス
　組織の壁
・まずはどれだけ時間がかかっているかを測った
　-> hello worldのシステムで、5ヶ月かかる。。。
　-> 競合他社、FinTechはもっと進んでいく
・pilotプロジェクト
　Jenkins > BitBucket > maven/JUnit/Jasmine > SonarQube > Artifactory
　数時間まで短縮 -> 全社展開へ！

●2016年
・Agileな開発
　SIerと成果で契約 -> 自社社員 + 他社とリソースを契約
・CI/CDのロードマップ
　マインドセットと習慣の変更
　スモールスタート
・啓蒙活動
　上層部を巻き込んだイベント
　コミュニティ
　コーチ
　70:20:10 = 本業:カイゼン:学び で時間を分けた
　成功と失敗を共有

●2017年
・IT4ITチームを組織
　バラバラのツールを統一
　CI Pipelineから、ツールを呼び出す
　テスト、デプロイの仕掛けを作った
・パイプライン
　splunk、XebiaLabs RELEASE、DEPLOY
　静的解析、セキュリティスキャン、依存性スキャンを並走
　->計測されたデータから管理者が判断
・CI/CDの成長
　高速化のために、マイクロサービスに分割
　分けたら、結合したテストが頻繁に必要
　パイプラインの要素ごとの担当チーム
　　コミュニケーションツール、テスト、メトリクス...
・成長に必要なこと
　上層部の承認が必要
　　※2歩下がってから、進むなどのアプローチも必要
　失敗は許容される心理的安全性をつくる
　小さなカイゼンを繰り返す
・自立した開発チーム
　Jenkinsを提供するチーム = 開発チームが依存 -> 自立できていない
　JenkinsをAWS上のコンテナで動作させて、必要に応じて作成/利用
　-> 収集したメトリクスはオンプレのまま、Jenkinsから連携させている

●次のステップ
・mesos -> k8s
・ハイブリッド/マルチクラウド
　・IBM CMS + AWS & Azure
・Cloud Native
　・PublicCloudを最大限活かすためのアプローチ
　・良いエンジニアを集めて定着させる
　・インフラの信頼性を上げる
・JenkinsとAWSサービスを組み合わせたパイプライン
　Jenkins
　　・jarまでのパイプライン
　　・コンテナのパイプライン
　　　※認証されたコンテナだけを利用するようにチェックしている
　　・git管理/container registory管理
　AWS
　　・CodeBuild
　　・CloudFormation

●Q&A
・Jenkinsを開発チームに渡すと統制が取れないのでは？
　セキュリティ分門に説明
　開発チームにも勉強会などを実施

■段階的なCI/CDの実現

テクマトリックス株式会社 / 酒井利治さん

●CI/CDの段階
0: 開発者ごとにビルド
1: 中央でビルド
　定期的にビルド
2: ビルドに続く他の処理を自動実行
　回帰テスト
　静的解析
　自動フィードバック
3: ジョブの並列実行
　やることが増えるのでエージェントを追加
4: 近隣のチームに適用
　Jenkinsに担当者割り当て
　設定やジョブ作成を支援
5: より多くのチームに適用
　pluginの競合などで、マスターを増やす
　各チームメンバーが管理
　Jenkins担当者がサポート
6: 全社的に適用
　ガバナンスが欠如
　管理作業の負担が増加
　チームの負担が増加
　CI/CDが部分最適化されてしまう
　-> CloudBees Core

●CloudBees Core
・Operations Center
　複数のマスターを管理
　「CloudBees Core Client Master」「Jenkins OSS Master」を登録、管理
　セキュリティ設定を一括管理
　アップデートセンター/クラスターオペレーション
・Client Master
　管理機能のついたmaster
　OSSからの移行はwarを差し替えるだけ
・共有エージェント
　複数のマスターが利用可能なエージェント
　特殊なハードウェアのエージェントを共有できる

●ポイント
・Kubernetes上で動かせる
・Masterをまたがってジョブを連携できる

●提供サービス
・Jenkinsトレーニング
・CI環境構築サービス
・CloudBees Jenkins Support
・TechMatrix Jenkins Platform Package

■DevOpsを前進させるCloudBeesの取り組み

CloudBees, Inc. / 川口耕介さん

●STEP1: BOTTOM-UP - Islands of CI
第一歩は、興味のある人が、ぽっと使い始める
CIの島が生まれる
現場でのコミュニケーションが広がっていく
-> フランケンシュタイン化したJenkins
　　40,000ジョブ on 1 Jenkinsなど

●STEP2: TOP-DOWN - Wake-up Call
なかなかトップは気づけない
テクノロジーを持った競合が参入すれば気づくが、それでは遅い

優秀なエンジニアには3倍の報酬を出している企業もあった
※日本の平均からしたら 10倍程度

 気が触れたほどの目標を設定
-> 今までとぜんぜん違う仕掛けが必要

●STEP3: Infrastructure Scale
ビジネスに合わせてインフラもスケール
バラ -> 中央集権 -> リソースをセルフコントロール

●STEP4: Logical Scale
気が触れたほどの目標を実現するには、インフラだけでは実現できない
考え方を変える必要がある。

 少人数のチームが、多数を劇的に楽にする

●STEP5: INSIGHTS - DevOptics
仕掛けで得られたプロセスのメトリクスをカイゼンにつなげる

●CloudBeesのコンセプト
Governance
　ルール付けられた開発プロセス
Visibility
　開発プロセスを可視化
Flexible
　ビジネスの成長に合わせて、業務プロセスも変わる
Scalable, Reliable, Elastic
　業務プロセスに合わせて、ソフトウェア開発も適応
-> CloudBees Suite

●CloudBees Suite
・DevOpticsは、ValueStreamを可視化する仕組み
・Coreは、中央で管理 & 個々でセルフコントロールする仕組み
・KubeCDは、k8sのノウハウをラップしている（JenkinsXベース）
・CodeShipでHostedもサポート

●HSBC Technologyの話
　毎年2000億円を投資
　テクノロジーの会社になる！
　が、時間が足りないから買う！

　主なレバーはDevOps
　DevOps = meta engineering
　　エンジニアリングのためのエンジニアリング
　　2段階でビジネスにテコが効く

　Production Deployまで全て自動化された
　次は自律化

●これからは全業種がソフトウェア企業
　トラクター x IoT から、収集したデータをビジネスへ
　鮭の収穫から缶詰めまでのプロセス内で遊びをどれだけ減らせるか、が利益につながる

 　CRMで気づいた。営業と開発は似ている。
　どちらの担当も、自分は職人と考えている
　どちらのVPも、クリエイティビティを残し、進む方向を揃えることを考える
　ここからシステムで、どう価値を生むか

　データモデルは、「データを理解するためのフレームワーク」
　アクティビティを記録して、データモデル/プロセスモデルを管理

　継続的な価値提供
　継続的な進化
　-> 継続的な経済活動

■全体のQ&A

●「苦労する」の肌感があるのはどの辺りか？
　Shared Serviceの人たちが
　「作ったよ、使って！」だと、みんなが苦労する
　「mono repo + 自動化の仕組みを提供」だと、みんなが楽
　どうすれば、文化や人に頼らず、この楽さを提供できるか。

●これからのJenkinsはどうなっていく？
　Jenkins Worldのスライドやビデオを見てね

●チェンジマネジメントをどう進めていくか？
　リーダーは、顧客やマーケットの声に耳を傾ける。
　リードタイムが長いと、リスクが高まる。
　縮めることで、リスクは下がる。
　小さくマーケットに価値を提供することで、仮説検証を進めていく。

　人は学ぶ生き物。「学びたい」という文化を創っていくことが大切。
　「やったことと、そこから生まれた価値」を伝え続けることで
　文化が広がっていく。

■感想

「共感」と「考えるところ」が、とても多いイベントでした。

ちょうど現場でShared Serviceのようなチームとして活動していて、Developer Data Platformのようなものを作って、開発プロセスのカイゼン案を仮説検証しようと活動を進めています。

これまでチームで提供してきた仕組みは「便利な仕組みを作ったよ。使って使ってー」な、川口さんの話されていた苦労するスタイルで、これを「どうPaaS的に提供していくか」の仮説検証でもあるので、方向性は間違っていなそう！と安心できました。

これまで直面してきた問題から、DevOpsな活動は、考え方やプロセスを変えていくのでチェンジマネジメントが必要という感覚がありました。
「正解」なアプローチは見つけられていませんが、今日のお話で共通で話していただけた内容で「そうですよね！みんな悩むポイントですよね！」と勝手に共感させていただいていました。
Jenkins Dayで、ここのお話が聞けると思っていなかったので、とても嬉しいです！

ただ、CloudBees Suiteを見ていると、大体は買えば済んでしまいそうで悩ましいですが。。。

とてもワクワクするイベントでした！ありがとうございます。