November 2023
Intermediate to advanced
472 pages
7h 12m
Japanese
DevOpsの世界は恐怖に満ちています。ダウンタイムの恐怖、データ損失の恐怖、セキュリティ違反の恐怖。変更を適用しようとするたび、何が起こるか気になります。どの環境でも同じように動くだろうか。別の障害を引き起こすだろうか。障害が起きたら、今回は問題を修正するため夜の何時まで起きていなければならないだろうか。企業が成長するにつれて、危険は大きくなり、デプロイのプロセスはより恐ろしいものになり、より間違いが発生しやすくなります。多くの企業はデプロイの頻度を下げることでこのリスクを回避しようとしますが、結果的に各デプロイは大きくなってしまいさらに障害が発生しやすくなります。
もしインフラをコードとして管理していれば、もっとよい方法でリスクを軽減できます。それはテストです。テストのゴールとは、変更を加えることに自信が持てるようになることです。ここでのキーワードは自信です。どんなテストのやり方も、コードにバグがないことは保証できません。したがって、これはむしろ確率の話なのです。すべてのインフラやデプロイプロセスをコードとして捉えられるなら、ステージング環境を含むプレ本番環境でコードをテスト可能です。しかもそれが動いたなら、全く同じコードが本番でも動く可能性は高いと言えます。恐怖と不確実性の世界において、高い確率と自信の大きさは、大いなる存在です。
この章では、インフラコードをテストするプロセスについて見ていきます。これには、手動テストと自動テストの両方が含まれますが、この章の多くは自動テストの方に割かれています。