「入門 継続的デリバリー」を読んだ感想
読んでから日があまり経つ前にということで、次の本についての感想を本記事に記載しておこかなと思う。
今までの「継続的インテグレーション」「継続的デリバリー」の書籍
最近では、「継続的インテグレーション」「継続的デリバリー」は（程度の差はあれど）一般的になってきているかとは思います。
これらに関する本として有名な本としては次があります。
これらの本は一定歴史があり（古典であり名著）、今でも役に立つ内容がいろいろと記載されています。
私が関わった本においてもCI/CDに関する章では上記の本を参考にしています。
とはいえ、少しかためであったりするため最初に手をつけるには腰が重くなるかなという点もあったかもしれません。
（やや古い本というのもありますし）
しかし、継続的インテグレーションも継続的デリバリーは利用されつつも、まだ活用しきれていない現場も多いのが実情なのではないかというのが私の肌感ではあります。
「入門 継続的デリバリー」で整えよう
そんな中、今回紹介する本である「入門 継続的デリバリー」が出版されました（原著は2022年になります）。
本書はタイトルのとおり「入門」といえる内容からスタートしています。
最初のうちは、これは弊社では当たり前にやってるよーと思っている方でも、読み進めるにつれて、ここまでは「まだ」やれてないなという話しになっているかもしれません。
最終的に全てを読み終えると身につくものは多く、中身は非常に濃いといえます。
上記のオライリーの公式ページから抜粋した章構成は次の通りです。
第1部 継続的デリバリーとは
1章 『入門 継続的デリバリー』へようこそ
2章 パイプラインの基本
第2部 常にデリバリー可能な状態に保つ
3章 バージョン管理は継続的デリバリーの成功に不可欠
4章 リントを効果的に使う
5章 ノイズの多いテストに対処する
6章 遅いテストスイートを速くする
7章 適切なタイミングで適切なシグナルを送る
第3部 デリバリーの簡略化
8章 簡単なデリバリーはバージョン管理から始まる
9章 安全かつ信頼性のあるビルド
10章 自信を持ってデプロイを行う
第4部 継続的デリバリーのデザイン
11章 継続的デリバリーを始める
12章 スクリプトはコードでもある
13章 パイプラインのデザイン
本書では複数の「架空の企業」と「その企業が作っているプロダクト」を元に、どういった課題があり、その課題を解決するためにどういったことをするかというストーリーのもと、継続的インテグレーションや継続的デリバリーについて話していきます。
実際に「私の職場」も同様な状況だと思う方もいるのではないかと思います。
１つ１つがどこかしらのカンファレンスで聞きたくなるような重厚な話しだったりします。淡々と話すよりも、こういったストーリーがあった上で話されていることは分かりやすいと感じます。
私もかつて次のようなCI/CD周りに対する改善活動をコツコツをしたことがあり、それを思い出しました。 その活動（の１つ）の資料は次のような感じです。
誰が読むと良いものか
この手の書籍はSWEやSREといった職種の方が読むケースが多いのかもしれません。
ただ、CI/CD周りは「テスト」というキーワードが非常に多くなるところです。 従って、QAにまつわる職種の方も読んでおいたほうが得られるものが多いです。
ストーリーベースであるので、分かりやすいですし得られるものがあると思います。
まだ、CI/CDサービス周りに関われていない場合は本書を読んで、その一歩を進めるのが良いのではないかと思います。
書かれている内容を全てそのまま活用すればいいわけではない
本書は良い本だと思いますが、私自身は書かれている内容全てに同意するわけではありません。
（そもそも本に書かれている内容を100％、そのまま活用するわけではなく自分たちにあった形に変えていくのが大事なことだと思っています）
カバレッジについて
たとえばカバレッジの話しのところで次のような記載があります。
例えば、80％のカバレッジを目標とする、などの閾値を設定すると、ときとしてあまり価値のないテストを書いてしまうこともあります。
目標に対してあと0.5%のカバレッジが必要であった場合、いくつか余分な（価値のない）テストを書いてしまう、というような場合です。
しかし、その数個の余分なテストを書く労力は、明示的な（80％という数字）目標の達成を自動化することと比べると、目をつぶれる程度のものです。
カバレッジは80%という数字が独り歩きしている印象が強いです。
カバレッジ自体は次（など）によってあるべき数値は異なると思っています。
対象となるプロダクト
プロダクトに求められる品質水準
対象となる技術領域
サーバに比べてフロント、特にモバイルは80％というのは現実的な「意味のある」数字と思っていません
また、数字を追う結果として、上記の引用文にあるような無価値なコードを増やすことは良くないと考えています。
コードはすべてメンテナンス対象です。
価値のないコードを増やすことはメンテナンスコストが増えることにも繋ががります。
世にある数値についての話しについては次のようなブログ記事を書きました。
E2Eテスト（自動テスト）について
他にE2Eテストの話しで次のような記載があります。
新しいE2Eテストを初めてわずか数週間で、サービス間のバグをいくつも発見することができたのです。
これがE2Eテストを実装しはじめた時点でバグを見つけたのか、動かし始めて上記のようにいくつものバグを見つけたので意味合いは変わります。もし、後者であれば問題がある状況だと思っています。
E2Eテストについては次のようなブログ記事を書きました。
テスト自動化という言葉について
次のような記載が本書にはあります。
テストは自動化できますか？
[中略] 以前に検出された障害に基づくチェックリストに従ってテストを実践している場合、自動化をする良いチャンスになります。 [中略]
私はこのようなチェックリストを元にした「手動テスト」を「自動化」するというアプローチはあまり好みではなく、アンチパターンだと思っています。
本書は、どうしても「継続的デリバリー」の話しが中心となるため、QAという面における内容においてはそこまで濃くないと思っています。
いかにテストを活用するかについて本書のテーマとしてまとめるのは難しいでしょうが、もう少し深堀りできていると良いなと思ったりしました。
おわりに
当然ですが、世にある本にある情報はそのまま鵜呑みにするのではなく、自分たちに合う形で変えていくのは前提だと思っています。
（とりあえず試してみて、失敗して改善をするというサイクルもありだとは思います）
本書は架空の企業やプロダクトを題材に色々と課題に対してアプローチをしています。
なので、そのまま鵜呑みにして適用するというケースが起こりうるかもしれませんが、それは気をつけたほうが良いと思います（とはいえ、このような書き方は非常に分かりやすいので、是非ともQAバージョンでも欲しいなと思いました）。
そういう注意すべき点はあれど、全般的に「継続的デリバリー」について色々と学べる良書だと思います。
この記事が気に入ったらサポートをしてみませんか？