CI/CD

Home

📕Arrow icon of a page linkサンエムシステム 上流工程標準(Preview版)

⚖️Arrow icon of a page linkサンエムシステム上流工程 標準規格

📘Arrow icon of a page link要件定義 実践ガイド

📘Arrow icon of a page link基本設計 実践ガイド

📄Arrow icon of a page linkテンプレート集

Get Started

📄Arrow icon of a page link基本設計工程のルール

📄Arrow icon of a page link基本設計書の構成を決める

🚧Arrow icon of a page link基本設計のプロセスモデル

実践ガイド

文書情報
システム方式設計
外部仕様設計
運用設計
インフラ設計
移行計画
テスト方針・計画
開発プロセス・規約
レビュー・承認

CI/CD

コードの統合からデプロイまでのプロセスを自動化し、品質を保ちながら迅速なリリースサイクルを実現するための設計ガイドです。

🎯 概要


  • 目的: コードの統合からデプロイまでのプロセスを自動化し、品質を保ちながら迅速なリリースサイクルを実現する。早期のバグ検出、人的ミスの削減、デプロイ時間の短縮を図る
  • スコープ: ビルド自動化、自動テスト実行、品質ゲート、デプロイパイプライン、環境ごとの承認フロー、秘密情報管理をカバーする。個別のテストケース詳細や運用監視設定は対象外
  • 推奨する実施タイミング: 基本設計の後半、開発環境構築と並行して実施する
  • 関連するステークホルダー: 開発チーム、インフラチーム、セキュリティチーム、プロジェクトマネージャー、品質管理チーム

📥 重要な前提知識・インプット


  • 前提知識: Git/GitHubの基本操作、YAML構文、シェルスクリプト、Docker基礎、自動テストの概念、デプロイプロセスの理解
  • インプット: システムアーキテクチャ設計書、技術スタック一覧、環境構成情報(Dev/Staging/Production)、テスト要件、品質基準、承認フロー

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]CI/CD
  • 必須要素: CI/CDパイプライン定義ファイル(YAML)、品質ゲート定義、環境別デプロイフロー図、秘密情報管理方針、ビルド・テスト・デプロイ手順書
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
秘密情報の保護 パスワード、APIキーなどがソースコードに含まれていない
テストの実行 全ての環境でユニットテスト・統合テストが実行される
品質ゲートの設定 カバレッジ基準、静的解析基準が満たされない場合にビルドが失敗する
本番デプロイの承認 本番環境へのデプロイに手動承認が必須となっている
ロールバック手順 デプロイ失敗時のロールバック手順が明確である

👁️‍🗨️ レビュー観点:

  • セキュリティ: 秘密情報が適切に管理され、ソースコードに含まれていないか
  • 品質保証: テストカバレッジ、静的解析、セキュリティスキャンが適切に実行されているか
  • 承認フロー: 本番環境へのデプロイに適切な承認プロセスが組み込まれているか
  • 自動化の範囲: 手作業を最小限にし、人的ミスを防ぐ自動化が実現されているか
  • トレーサビリティ: ビルド・デプロイの履歴が記録され、追跡可能か
  • エラーハンドリング: パイプライン失敗時の通知とロールバックが適切に設計されているか
🧪成果物のサンプル
# CI/CD

## CI/CDの目的

**Continuous Integration(継続的インテグレーション):**
- コードの統合を頻繁に行い、早期に問題を発見
- 自動テストによる品質の維持
- ビルドの自動化による効率化

**Continuous Delivery/Deployment(継続的デリバリー/デプロイメント):**
- 本番環境への迅速なリリース
- デプロイプロセスの自動化
- リリースサイクルの短縮

**主な目的:**
- **品質向上**: 自動テストによる早期バグ検出
- **効率化**: 手作業の削減、人的ミスの防止
- **迅速性**: 開発からリリースまでの時間短縮
- **一貫性**: 環境ごとの差異を最小化
- **トレーサビリティ**: ビルド・デプロイ履歴の記録

---

## CI/CDプラットフォーム

### 利用するプラットフォーム

本システムでは、GitHub Actions と AWS CodeSeries を組み合わせる。

---

## CI/CDの実装

具体的な仕様定義・実装は、開発工程に委ねる。

### 全体フロー概観

```mermaid
graph TB
    A[ソースコード] --> B[CI/CDプラットフォーム]
    B --> C[ビルド]
    B --> D[テスト]
    B --> E[デプロイ]
    C --> F[成果物]
    D --> G[テストレポート]
    E --> H[各環境]
```

### 禁止事項

#### ❌ ソースコードへの秘密情報の記述
```yaml
# NG例
env:
  DB_PASSWORD: "mypassword123"  # 秘密情報を直接記述
```

#### ❌ 本番環境への自動デプロイ(承認なし)
```yaml
# NG例
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Production
        run: ./deploy-prod.sh  # 承認なしで本番デプロイ
```

#### ❌ テストのスキップ
```yaml
# NG例
- name: Run Tests
  run: echo "Skipping tests"  # テストを実行しない
```

### 必須事項

#### ✅ 秘密情報の適切な管理
```yaml
# OK例: GitHub Secretsを使用
env:
  DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
```

#### ✅ 全環境でのテスト実行
```yaml
# OK例
- name: Run Unit Tests
  run: npm test
- name: Run Integration Tests
  run: npm run test:integration
```

#### ✅ 本番環境へのデプロイ承認
```yaml
# OK例
jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://prod.example.com
    steps:
      - name: Deploy
        run: ./deploy.sh
```

### 推奨事項

#### 🔵 並列実行によるビルド時間短縮
```yaml
# 推奨例
jobs:
  test:
    strategy:
      matrix:
        node-version: [14, 16, 18]
    runs-on: ubuntu-latest
    steps:
      - name: Test on Node ${{ matrix.node-version }}
        run: npm test
```

#### 🔵 キャッシュの活用
```yaml
# 推奨例
- name: Cache dependencies
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
```

#### 🔵 失敗時の通知
```yaml
# 推奨例
- name: Notify on failure
  if: failure()
  uses: 8398a7/action-slack@v3
  with:
    status: ${{ job.status }}
    webhook_url: ${{ secrets.SLACK_WEBHOOK }}
```

---

## 品質ゲート

### 品質基準

```mermaid
graph TD
    A[コード変更] --> B{静的解析}
    B -->|Pass| C{テストカバレッジ}
    B -->|Fail| Z[マージ拒否]
    C -->|>80%| D{ユニットテスト}
    C -->|<80%| Z
    D -->|Pass| E{統合テスト}
    D -->|Fail| Z
    E -->|Pass| F[マージ可能]
    E -->|Fail| Z
```

| 項目 | 基準 | ツール |
|------|------|--------|
| テストカバレッジ | 80%以上 | JaCoCo, Istanbul |
| 静的解析 | 警告なし | ESLint, SonarQube |
| セキュリティスキャン | 脆弱性なし | Snyk, Trivy |
| ビルド成功 | 必須 | Maven, npm |

---

🔄 設計の進め方・プロセス


🏗️ プロセス1: CI/CDプラットフォームとパイプライン全体設計

設計対象:

採用するCI/CDプラットフォームを選定し、コード変更からデプロイまでの全体フローを設計する。

具体例:

  • どのCI/CDプラットフォームを使うか(GitHub Actions、GitLab CI、Jenkins、AWS CodePipeline、Azure DevOpsなど)
  • ソースコードのブランチ戦略(Git Flow、GitHub Flow、Trunk-based developmentなど)をどうするか
  • どのブランチへのプッシュやプルリクエストでパイプラインをトリガーするか
  • ビルド → テスト → デプロイの全体フローをどう構成するか
  • どの環境(Dev、Staging、Production)にいつデプロイするか

設計原則:

  • 段階的なデプロイ: 開発環境 → ステージング環境 → 本番環境の順で段階的にデプロイし、各段階で検証を行う
  • 本番環境の保護: 本番環境へのデプロイには必ず承認フローを設け、自動デプロイを避ける
  • 高速フィードバック: ビルドやテストは可能な限り並列実行し、開発者へのフィードバックを早くする
  • 冪等性の確保: 同じパイプラインを複数回実行しても同じ結果になるよう設計する
  • トレーサビリティ: どのコミットがいつどの環境にデプロイされたか追跡できるようにする

文書化の推奨表現:

  • パイプラインフロー図の作成: Mermaidなどで視覚的にCI/CDの全体フローを表現する
  • ブランチ戦略の明記: どのブランチがどの環境に対応し、マージ・デプロイのルールは何かを文書化する
  • プラットフォーム選定理由: なぜそのCI/CDツールを選んだのか、チームスキル、コスト、既存システムとの統合性を含めて記録する
  • 環境ごとのデプロイ条件: 各環境へのデプロイトリガー(自動/手動)、承認者、実行タイミングを明確にする
🏗️ プロセス2: ビルド・テスト・品質ゲートの設計

設計対象:

ソースコードのビルド、自動テスト実行、品質基準チェックのプロセスを設計する。

具体例:

  • ビルドツール(Maven、Gradle、npm、Dockerなど)を何にするか
  • どのテストを自動実行するか(ユニットテスト、統合テスト、E2Eテストなど)
  • テストカバレッジの基準は何%にするか
  • 静的解析ツール(ESLint、SonarQube、Checkstyleなど)で何をチェックするか
  • セキュリティスキャン(Snyk、Trivy、OWASPなど)をどこで実行するか
  • 品質基準を満たさない場合の扱い(ビルド失敗、警告のみなど)をどうするか

設計原則:

  • 品質の自動保証: 人手によるチェックではなく、自動テストと静的解析で品質を保証する
  • 早期フィードバック: テストは可能な限り早い段階(プルリクエスト時など)で実行し、問題を早期発見する
  • 明確な品質基準: カバレッジ、静的解析、セキュリティの基準を数値で明確にし、基準未達時はマージを拒否する
  • 並列実行による高速化: テストスイートを分割し並列実行することで、パイプライン実行時間を短縮する
  • キャッシュの活用: 依存ライブラリのダウンロードなど、変更頻度の低い処理はキャッシュして高速化する

文書化の推奨表現:

  • 品質基準表の作成: テストカバレッジ、静的解析、セキュリティスキャンの具体的な基準値を表で整理する
  • 品質ゲートフローの図示: どのチェックをどの順序で実行し、どの基準で失敗とするかをフローチャートで示す
  • ツール選定理由の記録: 各品質チェックツールの選定理由、代替案との比較を文書化する
  • 例外ルールの明記: 一時的に品質基準を満たせない場合の例外承認プロセスがあれば記載する
🏗️ プロセス3: デプロイ戦略とセキュリティ

設計対象:

各環境へのデプロイ方式、承認フロー、秘密情報(パスワード、APIキー)の管理方法を設計する。

具体例:

  • 開発環境へは自動デプロイするか、手動承認を入れるか
  • ステージング環境へのデプロイタイミングはいつか(mainブランチマージ時、タグ作成時など)
  • 本番環境への承認者は誰か(プロジェクトマネージャー、テックリードなど)
  • データベースパスワード、APIキー、証明書などをどこに保管するか(GitHub Secrets、AWS Secrets Manager、Azure Key Vaultなど)
  • 環境変数をどのように管理するか(.envファイル、パラメータストアなど)
  • デプロイ失敗時のロールバック手順をどうするか

設計原則:

  • 秘密情報の厳格な管理: パスワード、APIキーは絶対にソースコードに含めず、専用の秘密情報管理サービスを使う
  • 本番環境の保護: 本番環境へのデプロイには必ず人間による承認を入れ、誤デプロイを防ぐ
  • 環境ごとの分離: 開発・ステージング・本番で異なる秘密情報を使い、環境間の影響を防ぐ
  • 最小権限の原則: CI/CDパイプラインには必要最小限の権限のみを付与し、セキュリティリスクを減らす
  • 監査ログの記録: 誰がいつどの環境にデプロイしたか、履歴を記録し追跡可能にする
  • ロールバック可能性: デプロイ失敗時に即座に前のバージョンに戻せる仕組みを用意する

文書化の推奨表現:

  • 環境別デプロイフローの図示: 各環境へのデプロイトリガー、承認者、自動/手動を明記したフロー図を作成する
  • 秘密情報管理表の作成: どの秘密情報をどのサービスで管理するか、一覧表で整理する
  • 承認フローの明記: 本番デプロイの承認者、承認基準、緊急時の対応手順を文書化する
  • ロールバック手順書: デプロイ失敗時の具体的なロールバック手順を記載する
  • 権限設定の文書化: CI/CDパイプラインに付与する権限の内容と理由を記録する

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク


  • 参考文献: 『Continuous Delivery』(Jez Humble, David Farley)、『The DevOps Handbook』、『Accelerate』
  • 関連する他のガイド: システムアーキテクチャ設計ガイド、セキュリティ設計ガイド、テスト戦略ガイド、環境構築ガイド
  • ツール・テンプレート: GitHub Actions公式ドキュメント、GitLab CI/CDドキュメント、AWS CodePipeline、Mermaidフローチャート


テンプレートサイト: 📄Arrow icon of a page linkテンプレート集