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

書籍

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

はじめに

読ませていただいた書籍は大変ボリュームがあるため、概要＋各部ごとの記事としてまとめます。 本記事は「第1部：基礎」についてです。

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

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

印象に残った点

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

「すべてバージョン管理に入れよ」はソフトウェアデリバリーの原則の1つ

• コードやドキュメントだけではなくプロビジョニングのスクリプトも入れる。
  • 確かに環境構築まで管理されることで厳密な環境構築が可能となる。保守していると環境再現さえできないこともあるのでこれが実現できればすごく効果が高い。
  • しかし、今携わっているプロジェクトはプロビジョニングのスクリプトがそもそも存在しない。
  • このことだけでもアカンね…構成管理の章をみても全然足りてない。改善していかないとイカンなぁ。

継続的インテグレーション(CI)はあくまで「プラクティス」であり、チームが規律を守ることが必要不可欠

• 継続的インテグレーションは真似れば出来る。ただ真似ただけでちゃんと運用として回るかどうかは別問題であり、ここにチームとして規律を守るという要素が絡んでくる。
  • 例えば、変更においてアプリケーションが壊れたら最優先タスクして修正することをプロジェクトとして合意しないといけない。
    • 規律なくして望むほどの品質向上にはつながらないとのこと。なるほど。これは肝に命じておきたい。

CIを始める前のプラクティス/基本的なプラクティス/やったほうがいいプラクティスが記載されている

• CIはプロジェクト途中から始めると多大な苦痛を伴う。そのためCIを始める前のプラクティスが必要となる。
  • 具体的には「定期的なチェックイン」、「包括的な自動テスト」、「ビルド&テストプロセスを短く保つ」、「開発ワークスペースを管理する」が挙げられる。
  • また、テストに時間がかかるのでステージを分け、コンパイル→ユニットテスト→バイナリコミットまでのステージとバイナリ取得→受け入れテスト以降をおこなうステージに分ける。
    • ステージを分けるという考えはなかった。確かにテスト時間かかるので分離は必要だ。
• CI時における基本的なプラクティス(3.5)、やったほうがいいプラクティス(3.6)が書かれている
  • ツールの使い方だと時代背景により廃れがあるものの、ノウハウ的なモノは普遍でありとても勉強になる。
• テストの種類としてブライアン・マリックが考えた「テストの四象限図」がある。(4.2)
  • みたことある。無理に自動化すべきではない点はあることは体感してる。メリハリだよね。
• レガシーシステムとは自動テストがないシステムのことであるby マイケル・フェザーズ(4.3.3)
  • 恥ずかしいことに、実務ではレガシーシステムしかみたことがないことになる...