カオナビのCIにおける自動テスト運用と速度改善 / CI automatic test operation and speed improvement

DevOpsDays Tokyo 2023で登壇した際の発表資料です。
https://confengine.com/conferences/devopsdays-tokyo-2023/proposal/18311/gitlab-cicd

本セッションでは、カオナビのCI/CD環境で運用を担当する二名のメンバーがそれぞれ直面してきた様々な事例を紹介します。

---

みなさんは、自動で実行され、エラーが発生しているにも関わらず無視され続けているテストを見たことはあるでしょうか？

前半は、そんな状態にあったカオナビの自動テストをGitLab CI/CDを活用して運用に乗せるまでの事例を紹介します。

---

セッションの後半では、CI/CDの速度改善の事例を紹介します。

・速度改善のためにデータ集計・可視化する

・他部署を巻き込んだ速度改善

Transcript

1. カオナビのCI/CDにおける 自動テスト運用と速度改善 © kaonavi, inc.
2. 山内 翼 DevOpsエンジニア 登壇者紹介 © kaonavi, inc. 2 成清 聡馬 DevOpsエンジニア image
3. タレントマネジメントシステム「カオナビ」 社員の個性・才能を発掘し 戦略人事を加速させるタレントマネジメントシステム © kaonavi, inc. 3
4. SRE部 サービス開発部 プロダクト開発チームの組織体制 プロダクト本部 アプリケーションの開発をしています。 インフラ基盤の開発をしています。 Data Frontier グループ データの正規化に関わるサービス・プロダクトのシステムを開発します。 Employee グループ 従業員レイヤーの方が使う機能を開発します。 Platform グループ システム全体の保守性を高める開発やアーキテクチャの見直しをします。 Kaizen1グループ, Kaizen2グループ 顧客側の改善業務に関わる機能を開発します。 Strategy グループ 経営や人事レイヤーの方が組織戦略で使う機能を開発します。 Productivity グループ CI/CD、E2Eテストなどの業務効率化を行います。 インフラ グループ 運用監視、障害対応、サーバ環境保守、 共通基盤の開発をします。 オペレーション グループ 不具合/インシデント対応、リリース管理、 デプロイ作業、顧客対応をします。 CTO室 企画推進本部 新規開発部 © kaonavi, inc. 4
5. SRE部 サービス開発部 プロダクト開発チームの組織体制 プロダクト本部 アプリケーションの開発をしています。 インフラ基盤の開発をしています。 Data Frontier グループ データの正規化に関わるサービス・プロダクトのシステムを開発します。 Employee グループ 従業員レイヤーの方が使う機能を開発します。 Platform グループ システム全体の保守性を高める開発やアーキテクチャの見直しをします。 Kaizen1グループ, Kaizen2グループ 顧客側の改善業務に関わる機能を開発します。 Strategy グループ 経営や人事レイヤーの方が組織戦略で使う機能を開発します。 Productivity グループ CI/CD、E2Eテストなどの業務効率化を行います。 インフラ グループ 運用監視、障害対応、サーバ環境保守、 共通基盤の開発をします。 オペレーション グループ 不具合/インシデント対応、リリース管理、 デプロイ作業、顧客対応をします。 CTO室 企画推進本部 新規開発部 © kaonavi, inc. 5
6. カオナビのCI/CDにおける 自動テストの変遷 2023.4.18 | 株式会社カオナビ　山内 翼 © kaonavi, inc.
7. 山内 翼 Tsubasa Yamauchi プロダクト本部 SRE部 Productivityグループ ・DevOpsエンジニア ・青森県出身 ・仙台でPHPエンジニア → CI/CDに興味を持ち始める ・現在はテスト環境構築などの運用業務をしながら 　CI/CDを始めとした自動化などの改善活動をしている 自己紹介 © kaonavi, inc. 7
8. Productivityグループについて © kaonavi, inc. 8 カオナビのProductivityグループは、 社内の生産性向上を目的とした部署です。 ・エンジニアの生産性を向上するために、運用業務を肩代わりしたり自動化したり 　→ 例えばエンジニアが必要なテスト環境の作成を代行し、自動化 ・もちろんエンジニア以外の生産性向上も目指します 　→最近はSalesforceへのデータ登録の自動化など
9. INDEX 1 . カオナビのCI/CDの概要（2020） 2 .使われなかったE2Eテスト 3 .リリース前検知をするために 4 .運用への組み込み © kaonavi, inc. 9 5 .GitLab CI/CD 自動テストのさらなる広がり
10. カオナビのCI/CDの概要（2020） © kaonavi, inc. 10
11. GitLabを使用 ・オンプレミス環境で GitLabを運用 ・GitLabに付属するGitLab CI/CDという機能を 　使用して自動テストなどを実行 カオナビのCI/CDの概要（2020） © kaonavi, inc. 11
12. PHPUnitなど、基本的な自動テストはCI/CDで実行可能 ・ユニットテストを書く文化は根付いており、 　GitLab CI/CDでコミットごとに自動実行 ・カバレッジ 約75％（当時） ・ユニットテストでは検知しきれない不具合も。。 カオナビのCI/CDの概要（2020） © kaonavi, inc. 12
13. ユニットテストでは検知しきれない不具合、例えば ・非ログインユーザーもアクセスするページで、 　ログイン前提のAPIが実行されてしまい認証エラー ・ブラウザのローカルストレージで保存していた内容が、 　別タブで参照できなくなってしまい、正しく表示されない。 カオナビのCI/CDの概要（2020） © kaonavi, inc. 13
14. ユニットテストとは別のテストが求められる ・「昨日の不具合、最近話題の E2Eテストがあれば検知できたんじゃ 　ないですか？」 ・「よし、じゃあカオナビでも E2Eテストを実装しよう」 ・「あの、実はE2Eテストはすでにあるんですけど。。」 カオナビのCI/CDの概要（2020） © kaonavi, inc. 14
15. 使われなかったE2Eテスト © kaonavi, inc. 15
16. 昔々あるところに、 E2Eテストがありました。 ・QC（品質管理）チームがテスト実施コスト軽減のため 　testcafeを使用したE2Eテストを作成 ・さらに運用しやすいよう、 GitLab CI/CDから 　ボタンひとつで実行できるように整備されていた 使われなかったE2Eテスト © kaonavi, inc. 16
17. このE2Eテストは使われなくなっていきました。。 © kaonavi, inc. 17
18. なぜ使われなくなってしまったのか ▶ テストへの信頼低下 ▶ テストの使いづらさ 使われなくなったE2Eテスト © kaonavi, inc. 18
19. なぜ使われなくなってしまったのか ・エンジニア不在で作成されたテストなので、ノーコードで作成 　→ Flaky Test（不安定なテスト）が大量に発生 　　→ カオナビのつくりとノーコードによるテストの相性が悪かった 　　→ 非エンジニアによる対応が難しい状態に ・機能追加によってテストが簡単に壊れてしまう ▶ テストへの信頼低下 使われなくなったE2Eテスト © kaonavi, inc. 19
20. なぜ使われなくなってしまったのか ・特定の環境・データに対してしか実行できない 　→ E2Eテストがデータに依存しており、専用の環境があった 　　→ その環境が誰にも使われていないことを確認してからテストを実行 　　→ テスト実施後にデータを実施前の状態に戻す「お掃除処理」があった 　→ E2Eテストが途中でコケるとデータが壊れる ▶ テストの使いづらさ 使われなくなったE2Eテスト © kaonavi, inc. 20
21. このE2Eテストを「使われるテスト」にしよう © kaonavi, inc. 21
22. ▶テストへの信頼低下 の解消 ・エンジニアが専任し、ひたすら不安定テスト潰しをしていく ・画面操作をライブラリ化することにより、機能変更に強いコードへ 　→ これについては昨年の DevOpsDaysでも発表しました 使われなくなったE2Eテスト © kaonavi, inc. 22
23. ▶テストの使いづらさ の解消 ・特定の環境・データに対してしか実行できない 使われなくなったE2Eテスト © kaonavi, inc. 23
24. ▶テストの使いづらさ の解消 ・特定の環境・データに対してしか実行できない 　→ 実行環境をCIの中に閉じ込めよう！ 使われなくなったE2Eテスト © kaonavi, inc. 24
25. 使われなくなったE2Eテスト © kaonavi, inc. 25 E2Eテスト実行環境をCIに閉じ込める　とは？ CI実行のたびにCI環境の中にローカル環境を立ち上げ、 そこに対してE2Eテストを実施するようにした。 GitLab Runner E2Eテストを実行
26. GitLab CI/CDでは、設定したDockerイメージをジョブの中で使用できる機能がある。 使われなくなったE2Eテスト © kaonavi, inc. 26 E2Eテスト実行環境をCIに閉じ込める　とは？ GitLab Runner
27. 今回はそこに docker in docker を指定。 docker in dockerの中にローカル環境のコンテナ + testcafeコンテナを置いた。 使われなくなったE2Eテスト © kaonavi, inc. 27 E2Eテスト実行環境をCIに閉じ込める　とは？ → 「特定の環境に対してしか実行できない」使いづらさを解消 GitLab Runner docker in docker web mysql testcafe
28. E2Eテスト実行用のdumpデータを用意しておき、 環境構築時に流し込む。 使われなくなったE2Eテスト © kaonavi, inc. 28 E2Eテスト実行環境をCIに閉じ込める　とは？ → 「テスト実行後にデータを元に戻さなければならない」使いづらさを解消 GitLab Runner docker in docker web mysql testcafe dump E2E 環境
29. 結果 ・やっぱりそんなに使われない ・一度信頼を失ったテストはなかなか根付かない。。 使われなくなったE2Eテスト © kaonavi, inc. 29 → 使われないならこっちから運用に乗せていこう
30. 運用への組み込み © kaonavi, inc. 30
31. どのように運用に乗せる？ ◆ 開発者が意識しなくてもテストが実行されている ◆ テストが落ちていたら開発者に通知し、修正を求める 運用への組み込み © kaonavi, inc. 31
32. どのように運用に乗せる？ ◆ 開発者が意識しなくてもテストが実行されている ・そもそも開発者が意識しないと実行されないから運用に乗らない ・ただし、E2Eテストは実行時間がかかるので無闇に実行はできない 運用への組み込み © kaonavi, inc. 32 → 毎日１回、リリースを控えた機能に対して自動実行するようにしよう。
33. E2Eテストの実行タイミング ・日次でリリース予定のチケットをまとめてマージしたブランチを作成し、 　そのブランチに対してE2Eテストを実行するようにした 運用への組み込み © kaonavi, inc. 33
34. master 1月1日 1月2日 1月3日 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定
35. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 毎日、masterブランチか らE2Eテスト用のブラン チを作成
36. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
37. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 直前テスト E2Eテストを自動実行 （直前テスト） 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
38. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 （直前テスト） 毎日、masterブランチか らE2Eテスト用のブラン チを作成 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ
39. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 draft/20230102 テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 （直前テスト） 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
40. master 1月1日 1月2日 1月3日 draft/20230101 feature/A feature/B feature/C 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 直前テスト ver1.0.1 draft/20230102 直前テスト テスト失敗時は原因特定。 必要に応じてリリース中止。 E2Eテストを自動実行 （直前テスト） 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 毎日、masterブランチか らE2Eテスト用のブラン チを作成
41. master 1月1日 1月2日 1月3日 draft/20230101 毎日、masterブランチか らE2Eテスト用のブラン チを作成 feature/A feature/B feature/C 明日リリース予定のブラ ンチをE2Eテスト用ブラン チにマージ 1/1 リリース予定 1/2 リリース予定 1/2 リリース予定 E2Eテストを自動実行 （直前テスト） 直前テスト テスト失敗時は原因特定。 必要に応じてリリース中止。 ver1.0.1 draft/20230102 ver1.0.2 ver1.0.3 直前テスト
42. どのように運用に乗せる？ ◆ テストが落ちていたら開発者に通知し、修正を求める ・いくらテストを実行しても、開発者に知らせて修正を促せなければ意味がない 運用への組み込み © kaonavi, inc. 42
43. 通知 ・成功／失敗をみんなが見る Slackに通知 ・失敗時は目を引くような通知にする ・失敗時にちゃんと騒ぐことで、 　テストの結果にメンバーを巻き込む © kaonavi, inc. 43 運用への組み込み
44. 通知 ・失敗時だけでなく成功時も通知すること 　で、詳しく知らない人にも「毎日何かのテ 　ストをやってるんだな」と思ってもらうの 　が重要 © kaonavi, inc. 44 運用への組み込み
45. 結果 ・運用に乗せることに成功 ・「テストを使ってもらう」のではなく、「テストが使われている」状態にする 　ことができた 運用への組み込み © kaonavi, inc. 45
46. GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 46
47. E2Eテスト実装後の展開 ・「前日ではなく、もっと早めに不具合を検知したい」との声 　→ 直前テストに加え、リリース予定に組み込まれた時点で実施するテストを追加 ・「明日リリース予定のブランチ」を手動でラベル付けしていたのが面倒、との声 　→ラベル付けを自動化 運用して初めて分かる不便や、新たに出てくる要望に合わせて改善をしていくフェーズへ GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 47 → 運用が根付いていっている！
48. まとめ ・使われないテストに対して、下記二点の改善に取り組んだ 　　・使いづらさ解消 　　・信頼性回復 ・それでも使われないテストは、積極的に運用に乗せてメンバーを巻き込むことで、 　「テストが使われている状態」に持っていくことが出来た GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 48
49. 学び ◇ 便利な自動テストの仕組みを作っただけでは、なかなか使ってもらえない ・これは自動化全般にもいえる GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 49
50. 学び ◇こちらから新しい仕組みを運用に乗せてしまう「攻めの運用」もときには重要 ・このとき、なるべく使う側の手間になることは避ける ・使う側が面倒なイメージを持ってしまったら仕組みは廃れていく GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 50
51. 学び ◇運用してみて初めてわかる不便さ・欠陥もある ・裏を返せば、それらを解消していけばさらに運用が根付いていく GitLab CI/CD 自動テストのさらなる広がり © kaonavi, inc. 51
52. カオナビの CI/CD 速度改善事例
53. image 成清 聡馬 Soma Narikiyo プロダクト本部 SRE部 Productivityグループ • 2022年 4月入社 • GitLab 周りの業務がメイン • 元々バックエンドエンジニア • Python と統計がマイブーム • イベント初登壇 自己紹介 © kaonavi, inc. 53
54. カオナビにおける CI/CD 環境 © kaonavi, inc. 54 GitLab Runner GitLab Runner GitLab Runner • GitLab CI/CD でパイプライ ンのジョブを実行するために 必要なアプリケーション。 • 複数のインスタンスに GitLab Runner をインス トールしている。 • インスタンスはオートスケー ルせず、台数固定で運用。 GitLab Runner EC2
55. GitLab CI/CD でジョブを実行する © kaonavi, inc. 55 worker worker worker GitLab Runner ジョブを実行するプロセス worker worker 数には上限値を 設定している runner GitLab とやりとりしたり、 worker を生成するエー ジェント runner 1つのインスタンスで複 数のジョブが実行される
56. パイプラインの説明 • ステージごとにジョブが存在する • 基本的には、ステージ内のジョブがすべ て終わらないと次のステージのジョブが 実行されない。
57. 運用していく中で起きうる問題 © kaonavi, inc. 57 運用上の問題 ジョブ実行時間の 上昇 ジョブ待ち時間の 上昇 失敗数の増加 • OOM Killer など • worker に空きがない • リソースの奪い合いによる、CPU 実行待ち、Disk IO 待ち
58. 問題は望んでなくてもやってくる
59. ことのはじまり © kaonavi, inc. 59 • アラートが頻繁に Slack に通知されるようになった
60. アラートの原因は Jest ジョブ © kaonavi, inc. 60 [deploy@prod-gitlab-runner01-a ~]$ ps aux --sort -%mem | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 13973 94.1 33.9 3153388 2654300 ? Dl 22:11 1:20 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13982 105 26.7 2585628 2086332 ? Rl 22:11 1:29 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13980 95.3 25.7 2513548 2014704 ? Rl 22:11 1:21 /usr/local/bin/node /builds/node_modules/jest-worker/build/workers/processChild.js root 13913 0.3 0.7 785948 59652 ? Sl 22:11 0:00 /usr/local/bin/node /usr/local/bin/yarn jest --testPathIgnorePatterns=__integration__ root 13900 0.2 0.7 785920 59616 ? Sl 22:11 0:00 node /usr/local/bin/yarn run test:ci deploy 14274 0.2 0.7 851228 58940 pts/1 Sl+ 22:12 0:00 docker volume rm runner-c8i7xc19-project-241-concurrent-0-cache-c33bcaa1fd2c77edfc3893b41966cea8 root 13935 1.2 0.7 674036 56752 ? Sl 22:11 0:01 /usr/local/bin/node /builds/node_modules/.bin/jest --testPathIgnorePatterns=__integration__ root 9447 3.9 0.6 1949856 52296 ? Ssl 20:21 4:26 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --default-ulimit nofile=1024:4096 root 9879 0.3 0.2 152228 23344 ? Ssl 20:21 0:23 gitlab-runner run --user=gitlab-runner --working-directory=/home/gitlab-runner • Jest ◦ JavaScript テスティングフレームワーク。フロントエンドのコード をテストするために使用。 • Jest ジョブがメモリを使いすぎているようだ 　 Jest: https://jestjs.io/ja/
61. パイプライン実行時間が上昇してくる © kaonavi, inc. 61
62. マネージャーに急かされる © kaonavi, inc. 62 パイプライン改善が急務になる！
63. 改善の前に・・・ © kaonavi, inc. 63 • 今まで CI/CD に関して、継続的にデータを取得してこなかった • この件をきっかけに、暫定対応しつつ、分析・モニタリングできる状 態をつくっていこう • データをもとに改善しよう • 断片的なデータしかなかったので、感覚・経験で運用してきた ◦ 「なんとなく」ジョブの実行時間が遅くなってきた ◦ 「なんとなく」ジョブが詰まっていそう
64. 分析って？ © kaonavi, inc. 64 仮説 計画 データ 分析 結論
65. 仮説 計画 データ 分析 結論 • 解決したい問 題を整理 • 仮説を立てる • 結論までの道 筋を作る • どのようなデー タが手に入れ ばいいか考え る • 計画に沿って データの収集・ 加工 • データを比較 する • 分析をまとめ 結論をだす 分析のプロセス 参考：安宅和人 .『イシューからはじめよ』 . 英治出版 . 2010
66. 今回のケースにあてはめる
67. 「パイプライン実行時間が延びている」、とは？ © kaonavi, inc. 67 パイプライン実行時 間が延びている ジョブの実行時間 が延びている ジョブの待ち時間が 延びている • 実行するコードが増えている • ハードウェアのリソース不足 • ジョブ数が増えている • ジョブの実行時間が延びている リソースを大量に消費するジョブがありパイプライン実行 時間に影響を与えている
68. どういう流れで結論にもっていくか？ リソースを大量に消 費するジョブがある リソース不足によっ て、ジョブの実行時間 が全体的に延びてい る ジョブの実行時間が長 くなっているので、ジョ ブの待ち時間も延びて いる パイプライン実行時間 が延びている
69. どうやってデータ収集する？ © kaonavi, inc. 69 データ インスタンスのリソー ス状況 ジョブ実行時間 ジョブ待ち時間 • Mackerel で確認 • GitLab の REST API を使ってデータ取得 • Python と pandas を 使ってデータ集計
70. データ収集の段階で気をつけたこと © kaonavi, inc. 70 • データを集めすぎない ◦ 分析を始めるとあれもこれも見たくなり、データを集めすぎてしまう ◦ 仮説を裏付けるデータがとれなくても、まずは分析の PDCA を 1 周させる • 必要以上に作り込まない ◦ コードが多少汚くても目的のデータが取得できれば OK • まずは小さく始める ◦ スプレッドシートにデータをためる ◦ データの可視化は、スプレッドシートのグラフ機能
71. 実際のデータ
72. メモリ使用状況 © kaonavi, inc. 72
73. メモリ使用状況
74. Jest 以外のジョブにも影響がでてる © kaonavi, inc. 74
75. ジョブの待ち時間も上昇している © kaonavi, inc. 75
76. Jest 対応策 ハードウェアで解 決 ソフトウェアで解 決 打ち手を考える Jest の設定を変 更する コードを書く 新しくインスタン スを追加する 既存のインスタン スで対応する 費用対効果が 高いのはどれ か検討する
77. 分析結果をもとに改善策を提案 © kaonavi, inc. 77 改善提案 現状 原因 打ち手 費用対効果 • パイプライン実行時間がxx分 • リリース作業に影響がでている • Jest ジョブがメモリを大量に使用している • Jest は専用のインスタンスで実行する • インスタンス追加でxx円/月発生 • パイプライン実行時間がxx分改善、 待ち時間がxx分改善
78. 効果測定 © kaonavi, inc. 78
79. パイプラインの実行時間は減少しました、めでたし
80. 問題にいち早く気づく方法はないか？
81. ダッシュボードの作成 © kaonavi, inc. 81 • Looker Studio でダッシュボード作成 • ジョブの実行時間、待ち時間を一目で分かるようにする
82. 分析のプロセス © kaonavi, inc. 82 仮説 計画 データ 分析 結論 • ダッシュボード 問題
83. パイプラインの問題は解決、最低限の分析もできるようになった
84. まだまだ改善できることはある © kaonavi, inc. 84 • ダッシュボードの作成によって、ジョブの状態が把握しやすくなった
85. まだまだ改善できることはある © kaonavi, inc. 85 • unit_test_4 の実行時間が改善できると、インパクトが大きそうだ • どうやって改善しよう・・・
86. 突然、協力者があらわれる
87. 50%短縮！！！ © kaonavi, inc. 87 • unit_test_4 の実行時間が、50%短縮 • 速度改善してくれたのは、別部署のエンジニア
88. なぜ別部署のエンジニアが改善してくれたのか？
89. 身近な人を頼る © kaonavi, inc. 89 SRE部 サービス開発部 サービス開発部 なら何か知ってる かな？ EM 改善できそう だぞ リードエンジニア会で 議題にあげとくわ UT の改善したいね ん
90. せっかく速度改善してくれたので、さらなる改善を目指す
91. 仲間を増やして、次の改善活動につなげる © kaonavi, inc. 91 速度改善あざっす もっと速度改善した いねん 改善案はいっぱいあ る 短期で改善できるもの と長期的に改善してい くものがあるで • 期間限定で、Slack に速度改善チャンネルを開設。短期で改善 できるものに取り組む • （部署問わず）速度改善に興味ある人がチャンネルに参加 改善してくれた人
92. パイプライン実行時間 84% 短縮
93. これまでの振り返り © kaonavi, inc. 93 計測 ツール コラボレーション • 状態の把握 • 仮説の検証 • 施策の効果測定 • 小さく始める • 作り込まない • 部署の垣根を越える • できる人の力を借りる 改善を進めた要素
94. 今後の展望 © kaonavi, inc. 94
95. 今後の展望 © kaonavi, inc. 95 • GitLab Runner のオートスケール ◦ CTO 室と連携して対応 ◦ 費用対効果の高い構成を目指す • テストコードの改善 ◦ Flaky Test の修正 ◦ 不要なテストコードの削除
96. DevOpsエンジニアを積極採用中！ ▼DevOpsエンジニア選考エントリー https://hrmos.co/pages/kaonavi/jobs/0000246 ▼その他求人エントリー https://corp.kaonavi.jp/recruit/list/?j=engineer ▼カジュアル面談エントリー https://hrmos.co/pages/kaonavi/jobs/casual21 ▼DevOpsエンジニアとして働くメンバーの紹介記事 https://vivivi.kaonavi.jp/articles/iwahara-masaki-220316/ https://vivivi.kaonavi.jp/articles/kushida-yosuke-220920/ https://vivivi.kaonavi.jp/articles/miyashita-hiroyuki-221013/