- CI/CDとは何か
- CI/CDの歴史と背景
- CI/CDが解決するソフトウェア開発の課題
[["統合地獄" (Integration Hell) の回避]][[手動プロセスの非効率性とヒューマンエラーの削減]][[デプロイメントの頻度向上とリードタイムの短縮]][[フィードバックループの高速化]]
- CI/CDのビジネス価値と利点
- CI/CDの3つの柱 (概要)
[[継続的インテグレーション (CI)]][[継続的デリバリー (CDelivery)]][[継続的デプロイメント (CDeployment)]]
- CIの定義 (開発者が変更を頻繁に中央リポジトリにマージし、自動ビルドとテストを実行するプラクティス)
- CIの主要な原則
[[単一のソースリポジトリの維持 (バージョン管理)]][[ビルドの自動化]][[テストの自動化]][[全員が毎日メインラインにコミットする (または頻繁に)]][[全てのコミットでメインラインのビルドとテストを実行する]][[ビルドとテストの結果を迅速にフィードバックする]][[壊れたビルドは最優先で修正する ("Fix the build immediately")]][[最新の実行可能ファイルを常に維持する]][[本番環境と同等のテスト環境の用意]][[誰でも最新の成果物を簡単に入手できる]][[全員がビルドとテストの結果を確認できる]][[デプロイメントの自動化 (CIの拡張としてのCD)]]
- CIのアンチパターン
[[頻繁でないインテグレーション]][[壊れたビルドの放置]][[自動テストの不足または信頼性の低いテスト]][[遅いビルドとテスト]][[コメントアウトされたテスト]][[ローカルでのみ成功するビルド]]
- CIの利点
[[バグの早期発見と修正コストの削減]][[コード品質の向上]][[開発サイクルの短縮]][[チームのコラボレーション促進]][[リリースの準備が常にできている状態 (部分的に)]]
- CIの課題
[[初期設定とメンテナンスのコスト]][[適切なテスト戦略の設計と実装]][[ビルドとテスト時間の管理]][[CIツールの選定と学習]][[チームの規律と文化の必要性]]
- CDeliveryの定義 (CIを拡張し、ソフトウェアの変更が自動的にテストされ、本番環境へのリリース準備が整った状態を常に維持するプラクティス)
- CDeliveryとCDeploymentの違い (本番へのデプロイが手動か自動か)
- CDeliveryの主要な原則
[[リリースのための全てのプロセスを自動化する]][[常にリリース可能な状態を維持する]][[誰でもワンクリックで (または簡単な手順で) 本番環境にデプロイできる]][[デプロイメントパイプラインの構築]][[品質保証の組み込み (様々なテストフェーズ)]][[フィードバックループの重視]][[インクリメンタルなリリース]][[全員が責任を持つ文化]]
- デプロイメントパイプラインとは (ソフトウェアがバージョン管理から本番ユーザーの手に渡るまでの自動化されたプロセス)
- 典型的なパイプラインステージ
[[コミットステージ (Commit Stage)]] (CIのビルドとユニット/インテグレーションテスト)[[受け入れテストステージ (Acceptance Test Stage)]]
[[本番に近い環境での自動受け入れテスト (UIテスト、APIテスト、E2Eテスト)]][[ユーザーストーリー/フィーチャーの検証]]
[[UATステージ (User Acceptance Test Stage) / 手動テストステージ]] (オプション、ビジネスによる検証)[[パフォーマンステストステージ (Performance Test Stage) / 負荷テストステージ]][[セキュリティテストステージ (Security Test Stage)]][[リリース準備ステージ (Release Staging)]] (最終的なビルド、リリース候補の作成)[[本番デプロイステージ (Production Deployment)]] (CDeliveryでは手動トリガー、CDeploymentでは自動)
- パイプラインの可視化と監視
- パイプラインの高速化と最適化
- CDeliveryの利点
[[リリースのリスクと複雑性の低減]][[より迅速で頻繁なリリース]][[高品質なソフトウェア]][[開発者の生産性向上 (手動作業からの解放)]][[顧客への価値提供の高速化]]
- CDeliveryの課題
[[高度な自動化とテスト戦略の必要性]][[環境管理の複雑性]][[組織文化の変革]][[データベース変更管理の難しさ]][[既存システムへの適用]]
- CDeploymentの定義 (CDeliveryをさらに進め、全ての変更が自動的にテストされ、問題がなければ自動的に本番環境にデプロイされるプラクティス)
- CDeploymentとCDeliveryの明確な違い (本番デプロイの自動化)
- CDeploymentの主要な原則
[[全ての変更が自動的に本番にデプロイされる]][[非常に高いレベルのテスト自動化と信頼性]][[堅牢な監視とロールバック戦略]][[フィーチャーフラグ (Feature Flags) の活用]][[段階的リリース戦略 (Canary, Blue/Greenなど)]]
- CDeploymentの利点
[[リードタイムの極限までの短縮]][[小さな変更単位での迅速なフィードバック]][[開発者のデプロイ作業からの完全な解放]]
- CDeploymentの課題とリスク
[[非常に高いテスト品質とカバレッジが必須]][[障害発生時の影響が大きい可能性 (迅速なロールバックが重要)]][[導入と維持のための高度な技術と文化]][[全ての種類のアプリケーションに適しているわけではない]]
- テストピラミッド (Test Pyramid) (ユニット、インテグレーション、E2E/UIテストのバランス)
[[ユニットテストの自動実行]][[インテグレーションテストの自動実行]][[受け入れテスト (E2Eテスト、UIテスト) の自動実行]]
[[Selenium, Cypress, Playwrightなどのツール]]
[[APIテストの自動実行]] (Postman/Newman, RestAssuredなど)[[パフォーマンステストの自動実行]] (JMeter, k6, Gatlingなど)[[セキュリティテストの自動実行 (SAST, DAST, IAST)]][[契約テスト (Contract Testing)]] (Pactなど)[[テスト結果の集約とレポート]]
- DevSecOpsの原則 (セキュリティをライフサイクル全体に統合)
- パイプラインにおけるセキュリティプラクティス
[[静的アプリケーションセキュリティテスト (SAST)]][[動的アプリケーションセキュリティテスト (DAST)]][[インタラクティブアプリケーションセキュリティテスト (IAST)]][[ソフトウェアコンポジション解析 (SCA - 依存関係の脆弱性スキャン)]][[コンテナイメージスキャン]][[Infrastructure as Code のセキュリティスキャン]][[シークレット管理 (Secrets Management)]] (Vault, Kubernetes Secretsなど)[[職務分掌とアクセス制御 (IAM)]][[監査ログ]]
- CD
- バージョン管理システム (VCS):
[[Git]], [[GitHub]], [[GitLab]], [[Bitbucket]]
- CI/CDサーバー/プラットフォーム:
[[Jenkins]], [[GitLab CI/CD]], [[GitHub Actions]], [[CircleCI]], [[Travis CI]], [[Azure DevOps Pipelines]], [[AWS CodePipeline]], [[Google Cloud Build]], [[TeamCity]], [[Bamboo]]
- ビルドツール:
[[Maven]], [[Gradle]], [[npm/yarn]], [[Webpack]], [[MSBuild]], [[Make]], [[Ant]]
- テストフレームワーク: (各言語のxUnit系),
[[Selenium]], [[Cypress]], [[Playwright]], [[Appium]], [[Jest]], [[Mocha]], [[PyTest]], [[RSpec]]
- コンテナ技術:
[[Docker]], [[containerd]], [[Podman]]
- コンテナオーケストレーション:
[[Kubernetes (K8s)]], [[Docker Swarm]], [[Amazon ECS]], [[Azure Kubernetes Service (AKS)], [[Google Kubernetes Engine (GKE)]]
- 構成管理ツール:
[[Ansible]], [[Chef]], [[Puppet]], [[SaltStack]]
- IaCツール:
[[Terraform]], [[AWS CloudFormation]], [[Azure Resource Manager (ARM)]], [[Pulumi]]
- モニタリングツール:
[[Prometheus]], [[Grafana]], [[ELK Stack (Elasticsearch, Logstash, Kibana)]], [[Datadog]], [[New Relic]], [[Dynatrace]]
- アーティファクトリポジトリ:
[[Nexus Repository]], [[JFrog Artifactory]], [[Docker Hub]], [[GitHub Packages]], [[AWS ECR]], [[Google Artifact Registry]]
- シークレット管理:
[[HashiCorp Vault]], [[AWS Secrets Manager]], [[Azure Key Vault]], [[Google Cloud Secret Manager]]
[[パイプラインを小さく、速く保つ]][[全ての変更をバージョン管理する (コード、設定、パイプライン定義)]][[テストを徹底的に自動化する]][[フィードバックを迅速かつ明確にする]][[本番環境とのパリティを保つ]][[インフラストラクチャもコードとして扱う (IaC)]][[セキュリティを早期から組み込む (Shift Left Security)]][[失敗からの迅速な復旧を可能にする]][[継続的な改善と計測]][[チーム全体で責任を持つ]]
[[CIシアター (CI Theater - CIツールは導入したがプラクティスが伴わない)]][[遅すぎるパイプライン / 長時間かかるビルド・テスト]][[不安定なテスト (Flaky Tests)]][[手動介入が多いパイプライン]][[本番環境との乖離が大きいテスト環境]][[巨大なコミット / 遅いマージ]][[フィードバックループの欠如または遅延]][[セキュリティチェックの無視または最終段階での実施]][[ツール依存とベンダーロックイン]][["私のマシンでは動く" (Works on my machine) 問題の放置]]
- CI/CD導入のロードマップ
- CD
- チーム構造とCI/CD
- CI/CD導入における課題と克服策
- CI/CD成熟度モデル (例)