23章 継続的インテグレーション
23.1 CIの概念
ビルドやテスト実行の情報を(中略)誰もが簡単に紹介できる、統合されたテスト報告システムがGoogleにはある
これについても1章割いて解説してほしかった
RollbarやSentryと比べて、どんな点が優れているか
実際は触っているコードに出たバグしか見なさそうな気もする
bugfixで車輪の再発明をしないようにするため、過去のバグも検索できるようにしている?
開発関係のタスクを自動化すると長期的にはエンジニアリングリソースの節約になる
リンクはSRE本の7章「Googleにおける自動化の進化」(邦題)だった
バージョンスキューを起きないようにシステム全体を設計することが本当に難しいなっていまだにおもう。
バージョンスキュー:アプリケーションの別々の部分が依存する同じソフトウェア部品のバージョンがばらばらにズレている状態(p.398)
API互換性
この問題点はGoogleではモノリポで解決している模様
同じシステム内部でもこれだけ大変なのだから、外部APIとなると何をか言わんや
「最新のCI結果がグリーンでないならコミットは不可」と述べるポリシーはおそらく誤解をしている。(中略)根本原因が十分に理解されており本番環境に影響しないことが明確なら、コミットをブロックするのは不合理
多くの現場でやっているであろう、原理主義から外れるアプローチにお墨付きを与えてくれるのは本書の良いところ
時間の節約のためには「問題ない」という判断を覚えておく人がいないといけないのだけど、このあたりはバグトラッカーでどうにかしているのだろうか
後ろの方に「自動化している」と書いてあった(さすGoogle
今後数年間にわたり、ソフトウェアエンジニアリングにおけるタスクは、テストとCIの状況の再定式化を促進するためにSREの既存のプラクティスのどの部分をCIの文脈で再構想できるか(攻略)
SREによってCIとテストが再定式化されるっていうのはしびれるな。自分も考えてみたい方向だ。
23.2 GoogleにおけるCI
ビルド警察
ビルド警察の責務は、特定プロジェクト内の全テストを、誰がそのテストを破綻させるかに関係なく、合格している状態に保つことだ
これ、やりたいけど特定個人に責任を集中させると本人の不満が蓄積してしまいそうでやれてない
fleakyなテストを見つけたらランダムでアサインされるようにしているけど、空いた時間でやるので対応が速いとは言い難い
あー。こういうのは交代制でやるといいんですかねぇ?
スクラムマスターやEMなどがやると良いかも
アプリケーションが急速に発展する場合には、決定的に重要である
CIを後回しにしてはいけない理由だ。
Takeoutの話が全般的にリアリティがたかくて学びが深くなるな
先にこの話を読んでから23.1 を読んだほうが理解しやすいかも?
優先順位づけがある前提でのテスト無効化はたしかに効果高いよなー。これだけ複雑な製品になるとよけいに実感することになりそう。
fleakyなテストが「見たことある」ベースで覚えていられるうちは良いけど、増えてたりいつの間にか直ってたり管理ができていないので、どうしようかと思っていた
起票&無効化ならオオカミ少年化を避けつつ管理できそう
無効化によって早めに対応するインセンティブにもなる。あとはメンバーの時間確保のサポートさえあれば
バグシステムと連携してシステムが自動でテストを有効化するとか本当に自動化に対してコストをはらっていてすごいなっておもう。
まず自動化を検討するのがGoogleらしくて良いですよね。この手の自動化、「何をどうする」の段階から検討するからコストを過大に見積もりがちで着手の腰が重い
きっと、だからこそ自動化を最初に検討している
「システム運用アンチパターン」に「品質を上げようとするがために承認者を作ってしまい、チームとしての仕事が増えてしまう→人がやるため判断がブレて、品質は却って下がってしまう」という話があった
23.3 結論
23.4 要約
CIは、早くて信頼性の高いテストがリポジトリー提出前に配置され、遅くて決定性の低いテストがリポジトリー提出後に配置されるように最適化されるべきである。
わかりやすいまとめだ。
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
感覚的にできるんだよなっていうのがあるんだけど、過度に標準化しようとして最初から諦めるっていうのはここ最近感じるかも?社内システムみたいなものをエンジニアが勢いで作っていくっていう動きを最近あまりみない気がする。
最近はお金払ってマネージドなサービス使ったほうが良い、という風潮
原因の仮説:「働き方改革」「セキュリティ意識の向上」「開発環境向けSaaSが増えた」「負債化しやすいので一周して皆懲りた?」
やり切るか、放置するかの二択
Google社内には放置されたプロダクトがゴロゴロしているのでは?
現場でどこまでできているか?
そこまで複雑なシステムを扱っていないからここまでCIに困っていない(シンプルなもので十分)っていうのがある。が、一部手動テストがあるので、そういうのも今後は自動化したいって思うと結構似たような話があって、書籍にはあるけど自分たちの現場ではできないという状況は起きそう。
密閉されたテスト、テストの解読不能なログを解消、グリーンに保つ あたりとか
割とウォーターフォールのプロジェクトでも結合テストではそれなりにバグが出て何度もテスト環境へのデプロイをしないといけないのでテスト環境へのCIやCDは当たり前にやるようになっていると感じる。
アジャイルならプロジェクト開始時点で当然CIやりますよねという暗黙の了解とまでなっているんじゃないだろうか
この本があるのになぜ実践する企業はすくないのか?
手運用でやっている方が引き継ぎやすいみたいな負の側面があるのかも?ハードスキルだと雇用の側面で苦労するんだけど、ソフトスキル重視の運用だと雇用でそこまで困らないみたいな。
盲目的に最初の段階でとりあえず静的解析、自動テスト、自動ビルドが動けばそれでCIはおしまいって思っているかもしれない。もっと世の中のプラクティスを学んでよりCIを発展させるところまで考慮できていないかも。
あまりCIに特化して「俺たちの考えた最強のCI」みたいな事例って聞くことが少なくなったかも。どう情報を集めたらいいかピンとこない。jenkins出始めとか、chatopsが流行った時とかは色々雑誌とかでも特集があった気がするけど。(自分があまりSREやSLOを学んでいないだけか?)
github actionsを試行錯誤してこうしたみたいなことはあまり見かけない
CIで自動化されるものが枯れてきた?
ChatGPTとかLLMで進化できるかも。レビューもそうだし、落ちた時にstacktraceから改善案とか、自動テストの考慮漏れや怪しいところを検知してくれるかも。
それの乗り越え方はなにか?
できるだけSaaSをつかったり、カスタムする領域を少なくしたり、デファクトスタンダード的な技術を選んだりするとかなのかなぁ。ユーザー数が多い技術を使うのは大事そう。
過去の勤務実績や営業実績からCIでの自動テストによるROIの高さを見える化していくのと、そういうのを導入するのが得意な人を雇うとかパートタイムで働いてもらうとかも必要かな。
エンジニアとして怠惰でいるために何をCIに組み込んで楽をしようとか、スクラムをやっているなら完成の定義を拡張するタイミングで見直したり
ステップを小さくするとしたらどうできそうか?
出来るだけ標準的なCIの構成をとりながら、自分たちのビジネスとして儲けている部分を直接的に支えるためだったら特別な対応をするみたいな方針をつくってみて、ROIを試算してみるとか?