「継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」を読んで(第2部)

書籍

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

はじめに

読ませていただいた書籍は大変ボリュームがあるため、概要＋各部ごとの記事としてまとめます。 本記事は「第2部：デプロイメントパイプライン」についてです。

その他の部についての記事は下記になります。

• 導入
• 第1部：基礎
• 第2部：デプロイメントパイプライン(本記事です。)
• 第3部：デリバリーエコシステム

印象に残った点

※　下記のカッコ書きは該当する章番号。

デプロイメントパイプラインの注意点/戦略/メトリクスについて記載されている

• デプロイメントパイプラインでバイナリを生成するのはコミットプロセス1回にする(5.3.1)
  • 再ビルドすると何らかの変更が混ざる可能性があり順々に行うテストの意味がなくなる。
  • またビルドには時間がかかるので何度も実施する必要がなければ不用意なビルドは避けるべき。
    • 自動ビルド/自動テストが出来ていない現状ではまだまだ先が長い…。
    • 自己学習の一環で自動ビルド/自動テストの実施をしていきたい。
• デプロイメントパイプラインを作成するためのインクリメンタルな戦略(5段階)がある(5.8)
  • 最小構成でかつ段階的に実施すると良いとのこと。
    • こう書かれてしまうと今からでもできてしまうなぁ。
• 変更してからデプロイするまでどれくらいかかるか?(=サイクルタイム)が1番プロセスについて教えてくれるメトリクス(5.9)
  • 欠陥数でのメトリクスは二次的で、リリースまでに時間がかかるのであれば欠陥数はあまり意味がない。
  • またコード行数やバグ件数はホーソン効果により実施者の振る舞いを変えてしまうので、計測するメトリクスはとても重要。
    • 現状の組織は欠陥数やコード行数をメトリクスにしている。良くない例の典型だ…。

ライブラリをプロジェクト毎ではなく組織としてリポジトリを作り管理すべき

• 組織としてリポジトリを作り、一元的にライブラリを管理する。
• 一元管理によりコンプライアンスが重要な組織では適切に承認されたライブラリのみを使えるようになる。(6.4.5)
  • 多重管理や不正な利用もコントロールできるので、組織的管理は必要だと思う。
  • また、医療ドメインの仕事をしているためSOUP管理は厳格にすべきなのは納得。

デプロイメントテストの前に環境/基盤用のスモークテストを用意する

• 環境/基盤が妥当化どうかのテストを事前に実施するという考え。
• 大事なのはアプリケーションが乗る基盤の保証ができているかいなか。
  • 環境を用意してもらってもネットワーク不良などにより利用できないことがあるので、環境の妥当性を確認できるテストは欲しいと感じた。

プロセスの自動化はいつやるか?の目安がある

• 自動化は同じことを2回やることになったとき。3回目からは自動化したほうが良い。(6.6.2)
  • 手動が許されるのは1度だけか…。回数はさておき、厳し方針を打ち出して対応すべきだとは思う。
  • 1部に記載があったが、チームの規律として徹底できるかどうかは別問題だと思い、そこが難しいと感じた。

テストが失敗したタイミングでパイプライン処理を終了させることはない

• ユニットテスト以外にもインテグレーションテストや受け入れテストを行うケースがあり、途中で止まっては勿体無い。(6.6.5)
• 包括的にテストした後、ビルドを失敗させると良い。
  • なるほど。確かに他のテストが可能であれば途中で落とす必要はない。

継続的インテグレーションに慣れていないチームに対するTipsがある

• チームが継続的インテグレーションに慣れていない場合にビルドマスターを置くと有効。(7.2.5)
  • 規律を身につけるためには設置し、週替りなどで交代することでCIに慣れさせるとあり、一人でやらせるべきではなく、良い学習機会になるとのこと。
    • 確かになぁ。これは今のプロジェクトに導入するにしてもその後が上手く回るように考えないといかんなぁ。

自動受け入れテストが欠かせない理由

• ユニットテストとコンポーネントテストだけで良いだろうという極端な主張をする人もいる
• しかしながら、ユーザーの求めるビジネス価値の証明点、大規模な修正ではユニットテストやコンポーネントテストは作り直すことになるが受け入れテストは使い回せる点をみても必要。(8.2)
  • 大幅に回収したいことはあるから受け入れテストあるといいよなぁー。
• コストが高くつくと思われているが効率性や費用対効果は十分みこめ、デリバリープロセスに対して、フィードバックループが短くなり、開発者、テスター、顧客の協力が進み、ビジネス価値に集中できるようになる。

受け入れテストの原則、考え方が存在する

• 受け入れテストはINVEST原則に従わなければならない(8.2.1)
  • INVEST原則はユーザーストーリーの文脈で使われる
• 受け入れ基準を書くためのドメイン特化言語がある
  • 前提(Given)、もし(When)、ならば(Then)で記述する。
• 受け入れテストは3層のレイヤで考える
  • 受け入れ基準、実装レイヤ、アプリケーションドライバレイヤ
  • 外部DSLであれば技術を知らなくてもかける。技術に精通してれば内部DSLが使え更に効率よくテストをかける。
• アプリケーションとのインタラクションを気にするのはアプリケーションドライバレイヤ。それより前はドメイン言語を使うべき。
• ウインドウドライバはアプリケーションドライバのプラグインと考える。
• 受け入れテストの所有権は開発者やテスターを含むデリバリーチーム全体で責任を持つ(8.6.1)
  • テストチームだと開発の時差が出てしまい、対応しようとしても新たな要求のテストにプラスして対応しないといけなくなり不良債権が積もるだけ。開発者も受け入れテストを保守する責任があると、新たな変更を加える際もテストスイートを意識するようになるというメリットもある。
    • なるほどなぁー。環境の用意だけではなく、マインドの定着もしないと破綻するということだろう。そこの意識を持たないと定着できんなぁ。
• 受け入れテストのパフォーマンスを維持するように努力しなければいけない。これはリファクタリングもする8.7.1)
  • テストケースもメンテが必要だということか。

非機能要件のテストの仕方の勘所が書かれている

• 非機能要件を分析する際は他の要件と同様に受け入れ基準のストーリーを作ると他の要件と同列で扱えるので良い(9.2.1)
  • 性能評価も同じように受け入れ基準のストーリーで検討可能である。
  • 基準はより「できるだけ早く」のように曖昧ではなく「2秒未満」のようにより詳細化しなくてはいけない。ただ、パフォーマンスという曖昧な書き方は良くないという事例も書かれていたり、パフォーマンスがユーザビリティ要件として書かれていたりするという良くない事例も書かれている。
    • ユーザビリティなのかパフォーマンスなのか?、パフォーマンスであればより詳細に!というのはスゴく納得できた。
• 早すぎる最適化は諸悪の根源である(9.3)
  • キャパシティテストは最適化すべきところを見つける為にする。推測するな計測せよ。
    • これはごもっとも。
  • 安定的なシステムを作るために「Release it!...」という素晴らしい本があるらしい
    • 読んでみたい!がボリュームありそうな本だなぁ。
• キャパシティ計測には相対的な方法(スケーラビリティテスト、長期稼働テスト)、絶対的な方法(スループットテスト、負荷テスト)がある。(9.4)
  • シナリオベースのテストでキャパシティテスト計画をすべき
    • 設計者目線ではないと。使う側目線でないといかんよ!ということだろう。
  • キャパシティの閾値は徐々に微調整するとよい。閾値に余裕があるせいで大幅なキャパシティダウンの変更に気づかず、最後のひと押しの小さなキャパシティダウンによって閾値を越えるような事態に早く気付けるようになる。
    • なるほど。この発想はなかった。常に閾値もメンテしないといけないんだなぁ。
• キャパシティテストの自動化は壊れやすく難しいので、既存の受け入れテストをいくつかピックアップし、キャパシティテスト用に書き換える方法がオススメ(9.6)
  • シナリオが反映されているため規模の拡大と成功の判断を足すだけで良いのか。なるほどねー。
• 受け入れテストの出力を記録し、テンプレート化して簡単に出力を複製できるようにする方法もある(9.6.3)
  • これは面白いなぁー。そういう機構を入れておけばキャパシティテストも簡単にできるのか。
• キャパシティテスト環境は本番環境に近くなるため、検証や調査を効率的に行える(9.8)
  • 確かになぁ。キャパシティテスト環境は品質面だけではなく他の利点もあるのか。

アプリケーションをデプロイ・リリースする勘所が書かれている

• アプリケーションの自動デプロイは、最初のイテレーションから準備しておくとよい。デプロイ先にバイナリを自動で送るプロセスはこのタイミングであると良い。(10.3)
  • なるほど。本の中で何度も出てくるが、疑似環境でも開発環境でも自動で環境構築できるようにしておけば、リリースのリスクマネジメントになるとのこと。
• デプロイプロセスに自動スモークテストを組みむことをおすすめする(10.3.2)
  • ここにスモークテストを組み込むのか。理にかなってるし、とても効率的だと感じる。
• リリース管理テクニックとして「ブルーグリーン・デプロイメント」がある(10.4.3)
  • 環境を2系統用意し、ルータによって本番環境を切り替える。バージョンアップも本番環境ではないほうで確認したのちルータで切り替えればオッケー。ただ、DBの巻き戻しには注意が必要。
    • ダウンタイムも少ないし理にかなってる。
• 緊急修正という場面でもいつもの手順から外れてはならない(10.5)
  • いつもの手順を踏まないといざ振り返ったときに何をやったか確認がとれない。
    • スゴく良く分かる。プロセスを軽んじる隣の課はやりそう。てか、やっている。アホは死んでも学ばない。