1. CI/CD入門 MOC
- CI/CDとは何か
- CI/CDの定義 (継続的インテグレーション、継続的デリバリー、継続的デプロイメントの総称)
- CI/CDの目的 (ソフトウェア開発とリリースの自動化、高速化、品質向上、リスク低減)
- CI/CDの歴史と背景
- ウォーターフォールモデルからアジャイル開発へ
- DevOpsムーブメントとCI/CDの関係
- CI/CDの進化と主要なマイルストーン
- CI/CDが解決するソフトウェア開発の課題
"統合地獄" (Integration Hell) の回避手動プロセスの非効率性とヒューマンエラーの削減デプロイメントの頻度向上とリードタイムの短縮フィードバックループの高速化
- CI/CDのビジネス価値と利点
- 市場投入までの時間短縮 (Time to Market)
- 開発効率と生産性の向上
- ソフトウェア品質の向上とバグの早期発見
- リリースの信頼性向上とデプロイリスクの低減
- 顧客満足度の向上
- イノベーションの促進
- CI/CDの3つの柱 (概要)
継続的インテグレーション (CI)継続的デリバリー (CDelivery)継続的デプロイメント (CDeployment)
2. 継続的インテグレーション (Continuous Integration - CI) MOC
2.1. CIの基本原則とプラクティス MOC
- CIの定義 (開発者が変更を頻繁に中央リポジトリにマージし、自動ビルドとテストを実行するプラクティス)
- CIの主要な原則
単一のソースリポジトリの維持 (バージョン管理)ビルドの自動化テストの自動化全員が毎日メインラインにコミットする (または頻繁に)全てのコミットでメインラインのビルドとテストを実行するビルドとテストの結果を迅速にフィードバックする壊れたビルドは最優先で修正する ("Fix the build immediately")最新の実行可能ファイルを常に維持する本番環境と同等のテスト環境の用意誰でも最新の成果物を簡単に入手できる全員がビルドとテストの結果を確認できるデプロイメントの自動化 (CIの拡張としてのCD)
- CIのアンチパターン
頻繁でないインテグレーション壊れたビルドの放置自動テストの不足または信頼性の低いテスト遅いビルドとテストコメントアウトされたテストローカルでのみ成功するビルド
2.2. CIのワークフローとプロセス MOC
- 開発者のローカル環境での作業 (コーディング、ローカルテスト)
- バージョン管理システムへのコミット (例: Git)
フィーチャーブランチ戦略とCIメインライン/トランクベース開発とCI
- CIサーバーによる変更の検知 (ポーリング、Webhook)
- 自動ビルドプロセスの実行
コードのチェックアウト依存関係の解決と取得コンパイル/トランスパイル静的コード解析 (Linting, Static Analysis)アーティファクトの作成 (実行ファイル、ライブラリ、コンテナイメージ)
- 自動テストプロセスの実行
ユニットテスト (Unit Tests)インテグレーションテスト (Integration Tests) - CIレベルコードカバレッジ測定
- ビルドとテスト結果の通知とレポート
成功/失敗のフィードバック (メール、チャット通知、ダッシュボード)テスト結果レポートの生成
- アーティファクトリポジトリへの成果物の格納
2.3. CIの利点と課題 MOC
- CIの利点
バグの早期発見と修正コストの削減コード品質の向上開発サイクルの短縮チームのコラボレーション促進リリースの準備が常にできている状態 (部分的に)
- CIの課題
初期設定とメンテナンスのコスト適切なテスト戦略の設計と実装ビルドとテスト時間の管理CIツールの選定と学習チームの規律と文化の必要性
3. 継続的デリバリー (Continuous Delivery - CDelivery) MOC
3.1. CDeliveryの基本原則とプラクティス MOC
- CDeliveryの定義 (CIを拡張し、ソフトウェアの変更が自動的にテストされ、本番環境へのリリース準備が整った状態を常に維持するプラクティス)
- CDeliveryとCDeploymentの違い (本番へのデプロイが手動か自動か)
- CDeliveryの主要な原則
リリースのための全てのプロセスを自動化する常にリリース可能な状態を維持する誰でもワンクリックで (または簡単な手順で) 本番環境にデプロイできるデプロイメントパイプラインの構築品質保証の組み込み (様々なテストフェーズ)フィードバックループの重視インクリメンタルなリリース全員が責任を持つ文化
3.2. CDeliveryのデプロイメントパイプライン MOC
- デプロイメントパイプラインとは (ソフトウェアがバージョン管理から本番ユーザーの手に渡るまでの自動化されたプロセス)
- 典型的なパイプラインステージ
コミットステージ (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では自動)
- パイプラインの可視化と監視
- パイプラインの高速化と最適化
3.3. CDeliveryの利点と課題 MOC
- CDeliveryの利点
リリースのリスクと複雑性の低減より迅速で頻繁なリリース高品質なソフトウェア開発者の生産性向上 (手動作業からの解放)顧客への価値提供の高速化
- CDeliveryの課題
高度な自動化とテスト戦略の必要性環境管理の複雑性組織文化の変革データベース変更管理の難しさ既存システムへの適用
4. 継続的デプロイメント (Continuous Deployment - CDeployment) MOC
4.1. CDeploymentの基本原則とプラクティス MOC
- CDeploymentの定義 (CDeliveryをさらに進め、全ての変更が自動的にテストされ、問題がなければ自動的に本番環境にデプロイされるプラクティス)
- CDeploymentとCDeliveryの明確な違い (本番デプロイの自動化)
- CDeploymentの主要な原則
全ての変更が自動的に本番にデプロイされる非常に高いレベルのテスト自動化と信頼性堅牢な監視とロールバック戦略フィーチャーフラグ (Feature Flags) の活用段階的リリース戦略 (Canary, Blue/Greenなど)
4.2. CDeploymentのパイプラインと要件 MOC
- CDeliveryパイプラインの完全自動化
- デプロイ後の自動検証と監視
- ロールバック戦略
- 高度な監視体制
リアルタイムモニタリング (パフォーマンス、エラーレート、ビジネスKPI)アラートシステム
4.3. CDeploymentの利点と課題 MOC
- CDeploymentの利点
リードタイムの極限までの短縮小さな変更単位での迅速なフィードバック開発者のデプロイ作業からの完全な解放
- CDeploymentの課題とリスク
非常に高いテスト品質とカバレッジが必須障害発生時の影響が大きい可能性 (迅速なロールバックが重要)導入と維持のための高度な技術と文化全ての種類のアプリケーションに適しているわけではない
5. CI/CDパイプラインの構築と管理要素 MOC
5.1. パイプライン・アズ・コード (Pipeline as Code) MOC
- Pipeline as Codeの定義 (CI/CDパイプラインの定義をコードとしてバージョン管理)
- Pipeline as Codeの利点 (再現性、バージョン管理、レビュー可能性、再利用性)
- 代表的なツール (Jenkinsfile (Jenkins), YAML (GitLab CI, GitHub Actions, CircleCI))
5.2. ビルド自動化 (Build Automation) MOC
- ビルドスクリプトの作成と管理
- ビルドツール (Maven, Gradle, npm, Webpack, MSBuild, Makeなど) の活用
- 依存関係管理 (Dependency Management)
- ビルド成果物 (Artifacts) の生成
5.3. テスト自動化 (Test Automation in CI/CD) MOC
- テストピラミッド (Test Pyramid) (ユニット、インテグレーション、E2E/UIテストのバランス)
ユニットテストの自動実行インテグレーションテストの自動実行受け入れテスト (E2Eテスト、UIテスト) の自動実行
Selenium, Cypress, Playwrightなどのツール
APIテストの自動実行 (Postman/Newman, RestAssuredなど)パフォーマンステストの自動実行 (JMeter, k6, Gatlingなど)セキュリティテストの自動実行 (SAST, DAST, IAST)契約テスト (Contract Testing) (Pactなど)テスト結果の集約とレポート
5.4. デプロイ自動化 (Deployment Automation) MOC
- デプロイ戦略 (Deployment Strategies) MOC
ビッグバンデプロイメント (Big Bang Deployment) - アンチパターンブルー/グリーンデプロイメント (Blue/Green Deployment)カナリアリリース (Canary Release)ローリングデプロイメント (Rolling Deployment)ダークローンチ (Dark Launching)A/Bテストとデプロイメント
- フィーチャーフラグ (Feature Flags / Feature Toggles) MOC
- 機能のオン/オフを動的に制御
- リスク低減と段階的公開
- デプロイスクリプトとツールの活用 (Ansible, Chef, Puppet, Terraform, Kubernetes)
5.5. 環境管理 (Environment Management in CI/CD) MOC
- 開発環境、テスト環境、ステージング環境、本番環境の分離と一貫性
- Infrastructure as Code (IaC) MOC
Terraform, AWS CloudFormation, Azure Resource Manager (ARM), Google Cloud Deployment Manager構成管理ツール (Ansible, Chef, Puppet, SaltStack)
- コンテナ技術 (Docker) とオーケストレーション (Kubernetes) MOC
- 環境のプロビジョニングと破棄の自動化
5.6. 監視とフィードバック (Monitoring and Feedback in CI/CD) MOC
- パイプラインの監視 (ビルド/デプロイ状況)
- アプリケーションパフォーマンスモニタリング (APM)
- インフラストラクチャモニタリング
- ログ管理 (集中ロギング - ELK Stack, Splunk, Grafana Loki)
- アラートシステム (異常検知と通知)
- ユーザーフィードバックの収集とパイプラインへの反映
- DORAメトリクス (Four Keys) とCI/CD (デプロイ頻度, リードタイム, 変更失敗率, 平均修復時間)
5.7. セキュリティ (Security in CI/CD - DevSecOps) MOC
- DevSecOpsの原則 (セキュリティをライフサイクル全体に統合)
- パイプラインにおけるセキュリティプラクティス
[[静的アプリケーションセキュリティテスト (SAST)]][[動的アプリケーションセキュリティテスト (DAST)]][[インタラクティブアプリケーションセキュリティテスト (IAST)]]ソフトウェアコンポジション解析 (SCA - 依存関係の脆弱性スキャン)[[コンテナイメージスキャン]]Infrastructure as Code のセキュリティスキャンシークレット管理 (Secrets Management) (Vault, Kubernetes Secretsなど)職務分掌とアクセス制御 (IAM)[[監査ログ]]
- 脅威モデリングとCI/CD
5.8. アーティファクト管理 (Artifact Management) MOC
- アーティファクトリポジトリの役割 (ビルド成果物の一元管理)
- バージョニングと依存関係管理
- 代表的なツール (Nexus Repository, JFrog Artifactory, Docker Hub, GitHub Packages, AWS ECR)
6. CI/CDツールとテクノロジー MOC (カテゴリ別主要ツール再掲・詳細)
- バージョン管理システム (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
7. CI/CDのベストプラクティスとアンチパターン MOC
7.1. CI/CDベストプラクティス MOC
パイプラインを小さく、速く保つ全ての変更をバージョン管理する (コード、設定、パイプライン定義)テストを徹底的に自動化するフィードバックを迅速かつ明確にする本番環境とのパリティを保つインフラストラクチャもコードとして扱う (IaC)セキュリティを早期から組み込む (Shift Left Security)失敗からの迅速な復旧を可能にする継続的な改善と計測チーム全体で責任を持つ
7.2. CI/CDアンチパターン MOC
CIシアター (CI Theater - CIツールは導入したがプラクティスが伴わない)遅すぎるパイプライン / 長時間かかるビルド・テスト不安定なテスト (Flaky Tests)手動介入が多いパイプライン本番環境との乖離が大きいテスト環境巨大なコミット / 遅いマージフィードバックループの欠如または遅延セキュリティチェックの無視または最終段階での実施ツール依存とベンダーロックイン"私のマシンでは動く" (Works on my machine) 問題の放置
8. CI/CDの導入と組織文化 MOC
- CI/CD導入のロードマップ
- 現状分析と目標設定
- スモールスタートと段階的導入
- ツールの選定とパイロットプロジェクト
- 全社展開と継続的改善
- DevOps文化とCI/CD
- コラボレーション、コミュニケーション、自動化
- 責任の共有と学習する文化
- チーム構造とCI/CD
- プラットフォームチーム / SREチームの役割
- 開発チームのオーナーシップ
- CI/CD導入における課題と克服策
- 技術的負債の التعامل
- 既存プロセスの抵抗
- スキルセットの不足
- ROIの証明
- CI/CD成熟度モデル (例)
9. CI/CDの将来と高度なトピック MOC
- GitOps MOC
- Gitを唯一の信頼できる情報源 (Single Source of Truth) とする運用
- 宣言的なインフラとアプリケーション構成
- Pullベースのデプロイメント
- AIOpsとCI/CD
- AI/MLを活用したパイプラインの最適化、異常検知、自動修復
- サーバーレスCI/CD
- Value Stream Management (VSM) とCI/CD
- プログレッシブデリバリー (Progressive Delivery) MOC (デプロイ戦略の進化形)
カナリアリリース、ブルー/グリーンデプロイメントの高度化フィーチャーフラグの積極活用トラフィック制御と段階的ロールアウト
- コンプライアンスと監査証跡の自動化 (Compliance as Code)
- エッジコンピューティングにおけるCI/CD