CI/CDのオフラインイベントに参加して、そのとき思ったことのメモです。
18:45~ | 開場
19:00~ | オープニング
19:10~ | LT * 5
- 開発生産性と開発者体験の向上に向けたCI/CD改善の取り組み：PRONI株式会社/末澤 尚也さん
- AWSで構築するCDパイプラインとその改善：株式会社スマートラウンド/山原 崇史さん
- CIは5分以内！素早い開発サイクルを支えるCI：ファインディ株式会社/浜田 直人さん
- CI/CDボトルネックの把握とその先へ：サイボウズ株式会社/加瀬 健太さん
- デプロイ再考2024：株式会社estie/杉田 毅博さん
20:20~ | 懇親会
参加の動機
私自身がこれからCI/CDをやっていく人としてまず「自組織のあるべき姿を描く」ため、自組織の現状と理想とのギャップを知る必要がある。理想状態を知るためには他社の取り組み知るのも１つの手だよなと思ったので、参加してみよう、という動機。
感想
結論、CI/CDの運用において、教科書的なベストプラクティスは存在しなさそうだ、という感想。他社事例を聞いている感じ、みんな泥臭い努力をして改善活動を行っているんだなと。
参加する前は「これが今のベストプラクティスや！」「こういうことやれば最適なCI/CDパイプラインの構築ができるやで！」という、" 現状のCI/CDの正解 " を見つけられるんだろうなと思っていたのですが、参加後の感想としては全然違うものになった。
参加してみて目指すべき方向の解像度が上がってスッキリすると思っていたけど、それどころかむしろモヤっとしてしまった、みたいな。
というのも、考慮すべき変数の多さを実感したんですよね。
当たり前と言えば当たり前なんだけど、環境によってほんとにいろいろと違う。プログラミング言語も違うしCI/CDツールの選定も、直面している課題も、組織の思想も、各社各様。一方で目指している方向としてはだいたい同じで、CIのスピードを上げようとか、CDの品質高めようとか。
すごく雑にまとめてしまうと、「CI/CDの文脈で存在するのは、そのプロダクトの歴史的背景と、社会的にこうあるべきという指標だけ...。 」みたいなものが分かって、モヤっとして終わった（思考がまとまらなかった）けど、新たな思考の出発点になったという点でめちゃくちゃ勉強になった。
そんな背景があり、教科書的に提案される内容は現場の変数を考慮しておらず、実際の現場との間には大きなギャップが存在するという意味で、ベストプラクティスは存在しなさそうだ、と思ったわけです。
定数と変数がある
ただ、「CIは早い方がいい！」というような感じで目指すべき方向性が明確なものもあれば、CI/CDの一部の観点でこれはベストプラクティスだ、と言えるような定数があることも理解しました。
- 定数：ベストプラクティス的な、みんなここを目指したらいいよ的な指標
- 変数：とはいえ組織によって差異があり、一概に「これがベスト」と言えない要因
定数と変数を加味して、組織におけるベターを選び取っていく必要がありそう。
定数
CI/CDパイプラインのフロー
CI/CDパイプラインのフローそれ自体は、品質向上、効率化、リリースの安定性を重視するためにベストプラクティスとして広く採用されているはずなので定数として認識してよさそう。
- ビルド
- テスト
- デプロイ
※ 実際には、様々な追加のステップやプロセスが含まれるがそれらは変数の認識
ソフトウェアデリバリーのパフォーマンス評価指標
LeanとDevOpsの科学 や State of DevOps Report（DevOps Research and Assessment による）からも分かるように、以下は全組織が目指すべきところ感、がある。
- リードタイム：コードコミットから本番環境で動作するまでの時間
- デプロイの頻度：変更を本番環境にpushする（デプロイやリリース）の頻度
- 平均修復時間：障害や不具合が見つかったときの復旧までの時間
- 変更失敗率：変更に伴うエラーや問題の発生率
上記（デリバリーのパフォーマンス）が高い組織は、組織文化を含む組織全体のパフォーマンス（収益性・市場占有率・生産性）と相関があることが示されている。目指すべき指標だねってことでこれは定数。
この辺を目指しているから、各社での具体的な取り組み（「CIの実行時間減らそうぜ、キャッシュ使う？並列処理？ネットワーク通信の量と頻度減らす？」みたいな試行錯誤）は似通ってくる。
変数
プロダクトとその歴史的背景
プロダクトの歴史が長ければ当然しがらみも増える。ツールの載せ替えも大変。以下はすべて変数としてとらえられそう。
- プログラミング言語
- ソースコード量
- テストコード量
- アーキテクチャ
- ツールが採用されてきた歴史的背景
- 組織の体制（そもそもCI/CDする部署やチームがあるか）
- 組織文化
この辺が違ってくると、他社では効果があった実装がうちでは効果なかった、みたいなことが起きる。また、それによって同じようなCI/CDパイプラインの構成にならない。
組織が重視する指標や観点
優先順位をどうつけるかは考え方次第。組織のニーズに合わせて調整が必要。
- パフォーマンス（速度）
- 安定性
- コスト効率
- 柔軟性・拡張性
- セキュリティ
- ユーザビリティ（開発者体験）
- オブザーバビリティ（可観測性）
例えばパフォーマンス（速度）が重要な組織では、高速なビルドやデプロイプロセスが重視される一方で、セキュリティが重要な組織では、ビルドの速度を落としてでもセキュリティテストや監査のためのプロセスなど追加のステップが必要になったりする。
まとめ
- 直面する課題が同じでも、いろいろな変数によって組織でできることが変わってくる（同じような前提だと勘違いしがち）
- 逆に、変数や組織の文脈を度外視したベストプラクティスを盲信すると身動きが取れなくなる
- 定数と変数のバランスを取りながら、自組織での最善をいろいろ実験していくしかない
おわりに
文字に起こしてしまえば何とも当たり前な話ではありますが、この投稿を１年後とかに振り返ってみて、どういう風に思考が変化しているのかを確かめるのが楽しみなので記事にしました。
また、イベントの内容とはちょっとズレた感想になった？気がしてるのですが、外部のイベント参加はとっても勉強になるので定期的に参加していきたいと思いました。