イベント概要と参加目的

昨今、開発生産性を向上させるために、スピードと品質の両立のためにもテストやデプロイといった部分を自動化が進んでいます。資源の統一化、一元的な管理等の対応は急務であり、CI/CDの考え方や取り組みについて、様々な組織で工夫が凝らされています。

CI/CD はとても関わる技術領域で,他社の事例を聞いてみたくて参加しました.

発表のサマリーと感想

各発表ごとにサマリと感想をまとめていきます.

@deliku0306さんによる CI/CD 改善の取組に関する発表でした.

CI は Github Actionsで CD が CodePipeline と CodeBuildの構成を取っている
CI実行改善の止めにやったこと: キャッシュの利用/job 並列実行/Large Runnerの利用/reviewdog で Linter解析結果をコメント/CI 実行結果を Slack 通知
- 今後の改善として CodeRabbit の AIコードレビュー導入を行う予定

発表資料

speakerdeck.com

@shonansurvivorsさんによる AWS での CD パイプライン構成をどうやってとっているか,またその改善に関する発表でした.

CD は本番環境の強い権限を持ちがちなのを権限管理ができる CodePipeline に寄せた
- CI は GitHub Actions
CodePipeline/CodeBuild で行う処理の例: Flyway の実行/ecspresso の実行/Serverless Framework のデプロイ
CD の品質を高めるために CD のコスパをよくして,速度と安定性を加味したパイプラインにする
- 加えてIAMの権限を最小限にする
開発者から CodeBuild の一部を動かしたいっていう要求に応えるために環境変数で動かせるようにしたり柔軟な制御を入れている

発表資料

speakerdeck.com

@hamchance0215さんによる CI の時間の短縮事例でした.

CI は10分が限界値で5分を切るようにしている
- 早くするための方法：GitHub Actions でテスト静的解析とセキュリティチェック
バックエンドで行った改善
- テストを直列でやると20~30分かかる
  - 並列実行する仕組みを作ってテストを8分割していることで5分以内にしている
フロントエンドで行った改善
- Typecheck に時間をかかっている
- Nxをつかって CI を高速化:モジュールの依存関係を管理できるようになっていて,依存関係を解釈して関連するところだけ CI を実行する
  - 変更した箇所と依存した部分だけ CI が実行されてキャッシュも使われるため高速化ができてる

発表資料

speakerdeck.com

@Kesin11さんによる CI/CD のボトルネック把握のための計測と解消に関する発表でした.

CI/CD の最適化としてやっていること
推測するな、計測せよ
- ボトルネックを先に把握する
- 意外なところに時間かかっているかもしれないから計測しよう
クリティカルパスから最適化
- 全体としてどこがクリティカルパスを把握して如何に早くするか
- どう分析するのか
  - GitHub Actions には遅いワークフローの分析ができないぞ...
    - actions-timeline(workflow の可視化ができる)
    - 可視化は Mermaid でやる
  - 設定は楽にできる
actions-timeline のその左記
- 可視化の先:ボトルネックの改善は知識と経験が必要
  - 毎回サポートするのはスケールしない
  - ので、基本的なアドバイスを代行してくれるツールが欲しい
  - actionlint では足りない...
キャッシュは時間が足りないので割愛
- 懇親会で聞きたかった...

発表資料

www.docswell.com

@sugitak06 さんによるデプロイの原則から自社での取り組みに関する発表でした.

プロダクトごとに技術スタックが違って複雑なので改めてデプロイとは何なのかを考えてみる
デプロイとはソフトウェアを実行可能な状態に持っていくこと
原則：ビルドとデプロイの2フェーズ
- ビルドにアプリケーションごとの差異はないし,事前にビルドやっていけば高速化できる
究極のデプロイ高速化のやり方
- Blue/Green Deploy と Feature Flag Deploy
estie 社の選択
- 事前ビルドを行っている
  - ビルドは dev でだけ行って、他の環境は tagging する
- ディスクイメージは全環境共用
CI/CD ツールはフロー整理のために使いたい
- アプリケーションごとの固有のロジックは入れない
- 実際の処理はスクリプトなどを用意して読み込ませる
- ビルドのロジックは Makefile とシェルスクリプトを外だし
  - 社内共通actionsを使って活用している