書籍「入門 継続的デリバリー」を読んでの学びをアウトプットする

目的

書籍「入門 継続的デリバリー」を読む機会ができたので、復習・知識の定着を目的として、学習した内容を殴り書きレベルでアウトプットします。

主観で気になった点をメモり、それをChatGPTで要約してもらうといったアウトプット形式になるので、個人のメモによるAIへのインプットに情報が影響されると思います。間違った解釈の場合もあり得るため、その点はご了承ください。

本記事の対象者は特におらず基本自分のための記事となりますが、もし本書に興味をお持ちの方がおられましたら、この記事が書籍の購入への後押しになれれば幸いです。

書籍紹介

入門 継続的デリバリー
-テストからリリースまでを安全に自動化するソフトウェアデリバリーのプロセス
出版：O'REILLY
発売日：2024/4/24

目次

序文
はじめに

第1部　継続的デリバリーとは

1章　『入門 継続的デリバリー』へようこそ
2章　パイプラインの基本

第2部　常にデリバリー可能な状態に保つ

3章　バージョン管理は継続的デリバリーの成功に不可欠
4章　リントを効果的に使う
5章　ノイズの多いテストに対処する
6章　遅いテストスイートを速くする
7章　適切なタイミングで適切なシグナルを送る

第3部　デリバリーの簡略化

8章　簡単なデリバリーはバージョン管理から始まる
9章　安全かつ信頼性のあるビルド
10章　自信を持ってデプロイを行う

第4部　継続的デリバリーのデザイン

11章　継続的デリバリーを始める
12章　スクリプトはコードでもある
13章　パイプラインのデザイン

付録
付録A　CDシステム
付録B　バージョン管理システム

章を読み終わり次第、随時更新予定です。

第1部　継続的デリバリーとは

1章　『入門 継続的デリバリー』へようこそ

📦 継続的デリバリー（Continuous Delivery）の概要と重要性

✅ なぜ継続的デリバリーが重要か？

• すべてのソフトウェア開発において有益
• 変更の迅速かつ安全なリリースが可能になることで、
  開発の品質・市場対応力・フィードバック速度を向上

📚 継続的デリバリーとは？

▶ 本書の定義

プロフェッショナルな品質のソフトウェアをエンジニアが思い通りに作成できるようにするためのプロセスの集合体

▶ CDF（Continuous Delivery Foundation）の定義

ソフトウェア開発チームが、変更を安全・迅速・持続的にリリースする手法
以下の2点を実現していることが条件：

1. いつでも変更をリリース可能である状態を保つ
2. リリースプロセスが自動化されている

▶ 継続的デリバリーの2つの目標

• いつでも安全に変更をリリース可能にすること
• ボタン一つで簡単にデリバリできる状態を実現すること

🧱 継続的デリバリーを支える活動

1. 継続的インテグレーション（CI）

• 変更をできる限り早く・頻繁に統合して検証
• 例：料理で新しい食材を加えるたびに味見をする
• コード変更のたびに、ビルド・テスト・静的解析などの自動検証を行う

2. 自動化されたリリースプロセス

• テスト、ビルド、リリース、デプロイなどを繰り返し実行可能な形で自動化
• CIの結果を受けて、そのまま本番環境に近い形でリリース準備を行う

🗂️ 用語と概念の整理

用語	定義
インテグレーション	複数人のコード変更を統合して、動作検証する行為
継続的インテグレーション（CI）	コード変更ごとにビルド・テスト・分析を自動実行して、変更の統合を信頼性の高いものにするプロセス
デリバリー	ビルド、リリース、デプロイなどのリリース準備全体を指す
継続的デプロイメント（CD）	コミットごとに自動でユーザ環境へリリースする仕組み
継続的デリバリー	動作可能なソフトウェアを、いつでも・安全に・意味のあるかたちで提供できる状態を保つ開発手法

🎯 結論

継続的デリバリーとは、ソフトウェアを「いつでも・安全に・自動でリリースできる」状態に保つための実践的な開発手法である。

それにより、開発スピード、品質、ユーザへの価値提供を最大化できる。

inputメモ

• 継続的デリバリーは必要か
  • Yes、どんなソフトウェアを作っているにせよ、継続的でプリオの原則を適用することで利益を得ることができる
• 継続的デリバリーとは

  • 本書の定義

    プロフェッショナルな品質のソフトウェアを書く複数のソフトウェアエンジニアが、思い通りのソフトウェアを作成できるようになるために必要なプロセスの集合体

  • CDFによる定義

    ソフトウェア開発において、チームがソフトウェアの変更を安全、迅速、かつ持続的にユーザにリリースする手法であり、以下２つを実践している。

    • いつでも変更がリリース可能であることを立証している
    • リリースプロセスを自動化している

  • 以上より、継続的デリバリーを実践するために達成すべき目標は２つ

    • いつでも安全にソフトウェアの変更を提供できる
    • ボタンを１つ押すぐらい簡単に、そのソフトウェアをデリバリできる

  • 上記を達成するための活動

    • 継続的インテグレーション
    • CIで変更点が検証されたら変更をリリースするプロセスの自動化、繰り返し実行可能性
• 用語

  • インテグレーション

    複数人によって行われるコードの変更を組み合わせて、そのコードが意図した通りに動くかどうかを検証する行為

  • 継続的インテグレーション

    • 例え
      • 料理で新しい食材を加えるたびに味見する
    • できる限り頻繁に、できる限り早く、変更をインテグレーションする

    チェックインの際に各変更を検証した上で、コードの変更を高い頻度で結合していくプロセスのこと

    エンジニアによるコードの変更をまとめる ＝ CIを利用するエンジニアが、変更を加えるたびにコードをコミットして共有のバージョンコントロールシステムにプッシュすることでテストやリンティングなどの自動化された検証が適用され、変更された複数のコードが結合されても機能を検証している

  • デリバリー

    • デリバリーする＝ビルド、リリース、デプロイ、などを含む

  • 継続的デプロイメント

    動作するソフトウェアは、コミットごとにユーザへ自動的にリリースされる

  • 継続的デリバリーの要素

    動作するソフトウェアを、プロジェクトにとって意味のある限り迅速に、いつでも安全にユーザにリリース可能な状態にしておくソフトウェア開発手法

2章　パイプラインの基本

✅ 概要

継続的デリバリー（CD）は、ソフトウェアを安全かつ迅速にユーザに届けるための仕組みであり、その中核は パイプラインとタスクによる自動化された処理の流れです。
この要約では、CDパイプラインの構成要素、タスクの種類、自動化トリガー、そして関連する用語について整理します。

📦 CDの前提：バージョン管理

• Gitなどのバージョン管理システム（VCS）を使用することがCDの前提
• コード履歴の管理、変更のトラッキング、マージコンフリクトの解消を自動化するために不可欠
• VCSにコードが存在しない限り、CDパイプラインの構築は困難

🔧 CDパイプラインの基本構成

パイプラインとは？

• コードの変更が入るエントリーポイント
• タスクを適切な順序・タイミングで実行する制御の役割

タスクとは？

• パイプライン内で実行される1つ1つの処理単位
• 例：テスト、ビルド、デプロイ など

🚀 CDパイプラインの基本タスク

タスク	説明
リント	静的解析により、コードのエラーやスタイル違反を検出
単体テスト・統合テスト	コードが正しく動作するかを確認
ビルド	コンテナイメージの作成などの変換処理
パブリッシュ	作成したイメージをレジストリにアップロード
デプロイ	新しいイメージで動作中ソフトウェアを更新

⚙️ 自動化のトリガーと実行タイミング

• Webhook：コードの更新（pushなど）に応じて、パイプラインを自動実行
• イベントベース：GitHub Actions, GitLab CI などで利用
• トリガーの役割：変更が発生した瞬間から自動でCDプロセスを開始できるようにする

📘 用語の整理

概念	別名・同義語
パイプライン	ワークフロー
タスク	ステージ、ジョブ、ビルド、ステップ
パイプライン実行環境	ノード、ランナー、エグゼキュータ、エージェント

✅ まとめ

継続的デリバリーを構成する主な要素は次の通りです：

1. コードはバージョン管理下にあることが必須
2. パイプラインが全体の処理の流れを管理し、タスクが実際の作業を担う
3. パイプラインはイベントにより自動的に起動される
4. 各タスクはリント → テスト → ビルド → パブリッシュ → デプロイという流れを基本とする
5. 「パイプライン」「タスク」といった用語には、実装ごとに別名がある

このように、CDは自動化と一貫性を通じて、高速で信頼性のあるソフトウェア配信を実現する基盤となります。

inputメモ

• ポイント
  • 基本的な構成要素であるパイプラインとタスクの扱い方
  • 基本的なCDパイプラインの要素（リント、テスト、ビルド、パブリッシュ、デプロイ）の学習
  • パイプラインの実行における自動化の役割（Webhook、イベント、トリガー）の理解
  • CDの分野における様々な用語について
• 内容
  • バージョン管理
    • Gitのようなバージョン管理システムを使うことは、CDの前提条件。コードの履歴とコンフリクトの検出が可能な場所に保存しない限り、CDを作成することは実質的に不可能
  • 用語定義
    • タスク
      • 実行する個々の作業
    • パイプライン
      • コードへのエントリポイントのようなもの、全てのタスクを適切なタイミングで適切な順序で呼び出す
  • CDパイプラインの基本タスク
    • リント
      • サービスのコードにある一般的なプログラミングエラーとスタイルエラーを検出。静的解析の最も一般的な形態。
    • 単体テストと統合テストの実行
      • サービスのコードが開発者の意図した通りに動作することを検証
    • イメージのビルド
      • 各サービス用のコンテナイメージをビルド
    • パブリッシュ
      • イメージレジストリにコンテナイメージをアップロード
    • デプロイ
      • 新しいイメージを使用して、動いているソフトウェアのバージョンを更新
  • パイプラインをいつどのように実行するか
    • バージョン管理システムのWebhookによるコード変更の通知自動化
      • パイプラインのトリガー
  • その他用語の定義
    • パイプラインが実行されるマシン＝ノード、ランナー、エグゼキュータ、エージェント
    • パイプライン＝ワークフロー
    • タスク＝ステージ、ジョブ、ビルド、ステップ

3章　バージョン管理は継続的デリバリーの成功に不可欠

✅ 概要

継続的デリバリー（CD）を成功させるためには、バージョン管理と**設定のコード化（Config as Code）**が不可欠です。
コードと設定をすべて追跡可能にし、変更をトリガーにパイプラインを自動実行することで、常にリリース可能な状態を保ちます。

📘 バージョン管理の役割

• **バージョン管理システム（VCS）**は、プレーンテキストの変更履歴を記録するツール（例：Git）
• **変更単位は「コミット」または「リビジョン」**と呼ばれ、リポジトリに格納される
• すべての変更の履歴を保持＝ソースコードの信頼できる出典（Source of Truth）

🚀 CDにおいてなぜバージョン管理が不可欠か？

• **変更を統合する方法（インテグレーション）**と、**変更を保存する場所（リポジトリ）**が必須
• バージョン管理により：
  • CIを通じて変更が自動でテストされ
  • CDパイプラインが最新の変更を契機にトリガーされる

🔄 リリース可能な状態を保つ方法

• バージョン管理を常にグリーン（テストが成功している状態）に保つ
• リモートリポジトリの変更をトリガーにして、自動でパイプラインを実行
• これにより、任意の時点でソフトウェアをリリース可能な状態に保てる

🛠️ Config as Code（構成のコード化）

• 設定ファイルをリポジトリに含めてコードと同様に管理
• 特徴：
  • 変更履歴が残る
  • 設定変更もコードレビューの対象になる
  • 自動デプロイと組み合わせやすい
• 機密データは外部のセキュアな仕組み（例：Secret Manager）で管理

📂 Source of Truth（信頼できる情報源）

• バージョン管理に置かれたコードと設定が、常に正しい状態を示す唯一の情報源
• 手動変更や人の記憶ではなく、リポジトリが「真実のソース」

✅ まとめ

継続的デリバリーを維持・進化させるうえで重要な実践：

1. すべてのコードと設定をバージョン管理に保存
2. Config as Code を採用し、インフラやアプリ設定も追跡可能に
3. リモートリポジトリの変更をきっかけにCDパイプラインを自動実行
4. 常にテスト済み・リリース可能な**「グリーンな状態」**を維持する
5. リポジトリが唯一の信頼できる情報源（Source of Truth）

このアプローチにより、一貫性・自動化・信頼性の高いリリースサイクルを実現できます。

inputメモ

• ポイント
  • 継続的デリバリーにバージョン管理が不可欠な理由を理解する
  • バージョン管理をグリーンな状態にし、バージョン管理の変更に基づきパイプラインをトリガーすることで、ソフトウェアをリリース可能な状態に維持する
  • 設定をコードとして定義する（Config as Code）
  • 全ての設定をバージョン管理することによって自動化を実現する
• 内容
  • バージョン管理は、プレーンテキストの変更を追跡するためのソフトウェア
    • 各変更はバージョンによって識別され、コミットまたはリビジョンとも呼ばれる
    • リポジトリ：保存する中心となる場所
    • バージョン：全ての変更の履歴
  • バージョン管理は継続的デリバリーの基礎となるもの
    • 継続的インテグレーションを行うには、変更を結合する方法と変更を保存する場所が必要
  • バージョン管理をリリース可能な状態に保つ
    • テストが実行されることを保証すること＝自動化
    • リモートリポジトリの変更を契機にパイプラインがトリガーされるように設定すること
  • Source of Truth
    • 信頼できるコードのバージョン
  • Config as Code
    • 設定ファイルをリポジトリに配置する
    • 機密データは別のシステムによって管理させる
    • ソフトウェアの設定をソースコードと同じように扱う

---

X章　Template

hoge

inputメモ