構成管理

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基本設計のプロセスモデル

実践ガイド

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

構成管理

システム開発における構成要素の一貫性を保ち、変更履歴を追跡可能にし、任意の時点の状態を再現できるようにするための管理手法を設計します。

🎯 概要


  • 目的: システムのソースコード、ビルド成果物、環境設定、依存ライブラリなどの構成要素を適切に管理し、すべての環境で一貫性のある動作を保証する。また、変更履歴を追跡可能にし、任意の時点の状態を再現できるようにする
  • スコープ: バージョン管理(Git)、ブランチ戦略、ビルド成果物の管理、依存ライブラリの管理、環境変数の管理、構成管理台帳の整備をカバーする。個別の開発環境のセットアップ手順は対象外
  • 推奨する実施タイミング: プロジェクト開始直後の基本設計初期段階で方針を策定し、開発期間を通じて継続的に実施する
  • 関連するステークホルダー: プロジェクトマネージャー、開発チームリーダー、開発者、インフラチーム、品質保証チーム

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


  • 前提知識: Git の基本操作、セマンティックバージョニング、ブランチ戦略(Git Flow/GitHub Flow)、CI/CD の基礎知識
  • インプット: 採用技術スタック一覧、開発環境要件、リリース計画、チーム開発体制

📄 成果物の定義


  • ドキュメントテンプレート: 📄Arrow icon of a page link[テンプレ]構成管理
  • 必須要素: バージョン管理方針書、ブランチ戦略定義書、構成管理台帳、依存ライブラリ管理方針、環境変数管理方針、リリース手順書
✅ 品質基準・レビュー観点

品質チェックリスト:

チェック項目 チェック内容
バージョン管理の完全性 すべてのソースコードと設定ファイルがバージョン管理されている
ブランチ戦略の遵守 定められたブランチ戦略に従った運用がされている
リリース追跡可能性 構成管理台帳ですべてのリリースが追跡可能である
依存ライブラリの健全性 脆弱性のあるライブラリが使用されていない
環境変数の適切な管理 秘密情報が適切に保護され、環境ごとに正しく設定されている

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

  • 再現性の保証: 構成管理台帳とタグ情報から、過去の任意のバージョンを再現できるか
  • 変更追跡の完全性: すべての変更がコミット履歴として記録され、理由が明確か
  • セキュリティ: 秘密情報がソースコードに含まれていない、脆弱性管理が適切か
  • チーム運用の実現可能性: 定義した方針がチーム全体で実践可能か、複雑すぎないか
🧪成果物のサンプル
# 構成管理

## 構成管理の目的

構成管理は、システム開発において以下を実現するための管理活動である:

- **一貫性の確保**: すべての環境で同じ構成を維持する
- **変更の追跡**: いつ、誰が、何を変更したかを記録する
- **再現性の保証**: 任意の時点の状態を再現可能にする
- **品質の維持**: 承認されていない変更を防止する
- **効率的な開発**: チーム全体で統一された環境を共有する

---

## 開発環境

### 推奨開発環境

| 項目 | 推奨ツール/バージョン | 備考 |
|------|---------------------|------|
| OS | Windows 11 / macOS 13+ / Ubuntu 22.04 LTS | - |
| IDE | Visual Studio Code / IntelliJ IDEA | プロジェクトに応じて選択 |
| ランタイム | Node.js 18 LTS / Java 17 | LTSバージョンを使用 |
| パッケージマネージャー | npm 9+ / Maven 3.8+ | - |
| コンテナ | Docker Desktop 4.x | ローカル開発環境の統一 |

### 環境セットアップ

```mermaid
graph LR
    A[リポジトリClone] --> B[依存関係インストール]
    B --> C[環境変数設定]
    C --> D[データベース初期化]
    D --> E[開発サーバー起動]
```

---

## バージョン管理

### バージョン管理システム

- **使用ツール**: Git
- **リポジトリホスティング**: GitHub / GitLab
- **ブランチ戦略**: Git Flow / GitHub Flow(プロジェクトに応じて選択)

### バージョニング

セマンティックバージョニング(Semantic Versioning 2.0.0)を採用する。

**形式**: `MAJOR.MINOR.PATCH`

- **MAJOR**: 互換性のない API 変更
- **MINOR**: 後方互換性のある機能追加
- **PATCH**: 後方互換性のあるバグ修正

****:
- `1.0.0` - 初回リリース
- `1.1.0` - 新機能追加
- `1.1.1` - バグ修正
- `2.0.0` - 破壊的変更を含むメジャーアップデート

### タグ管理

リリース時には必ずGitタグを付与する。

```bash
# タグの作成
git tag -a v1.2.0 -m "Release version 1.2.0"

# タグのプッシュ
git push origin v1.2.0
```

**タグ命名規則**:
- リリースタグ: `v{MAJOR}.{MINOR}.{PATCH}` (: `v1.2.0`)
- リリース候補: `v{MAJOR}.{MINOR}.{PATCH}-rc{N}` (: `v1.2.0-rc1`)

### 管理台帳

すべてのリリースバージョンと関連する構成情報を記録する。

| バージョン | リリース日 | 環境 | ブランチ | コミットハッシュ | 備考 |
|-----------|-----------|------|---------|----------------|------|
| v1.0.0 | 2025-01-15 | 本番 | main | a1b2c3d | 初回リリース |
| v1.1.0 | 2025-02-20 | 本番 | main | e4f5g6h | 新機能追加 |
| v1.1.1 | 2025-02-25 | 本番 | main | i7j8k9l | 緊急バグ修正 |

---

## アーティファクト管理

### アーティファクトの種類

```mermaid
graph TD
    A[アーティファクト] --> B[ソースコード]
    A --> C[ビルド成果物]
    A --> D[ドキュメント]
    
    B --> B1[アプリケーションコード]
    B --> B2[設定ファイル]
    
    C --> C1[実行ファイル]
    C --> C2[コンテナイメージ]
    
    D --> D1[設計書]
    D --> D2[API仕様書]
```

### アーティファクトリポジトリ

| 種類 | リポジトリ | 命名規則 | 保持期間 |
|------|-----------|---------|---------|
| Dockerイメージ | Docker Hub / ECR | `{project}/{service}:{version}` | 直近10バージョン |
| Jarファイル | Nexus / Artifactory | `{groupId}/{artifactId}/{version}` | すべて保持 |
| npmパッケージ | npm Registry | `@{scope}/{package}@{version}` | すべて保持 |

****:
- Dockerイメージ: `myproject/api-server:1.2.0`
- Jarファイル: `com.example/myapp/1.2.0/myapp-1.2.0.jar`

---

## 環境変数管理

環境ごとに異なる設定値を管理する。

```mermaid
graph LR
    A[環境変数] --> B[ローカル]
    A --> C[開発]
    A --> D[ステージング]
    A --> E[本番]
    
    B --> B1[.env.local]
    C --> C1[Parameter Store]
    D --> D1[Secrets Manager]
    E --> E1[Secrets Manager]
```

### 環境変数の分類

| 分類 || 管理方法 |
|------|----|---------| 
| 公開情報 | `APP_NAME`, `LOG_LEVEL` | ソースコードまたは設定ファイル |
| 環境依存 | `API_ENDPOINT`, `DB_HOST` | 環境変数 |
| 秘密情報 | `DB_PASSWORD`, `API_KEY` | 秘密情報管理システム |

---

## 依存関係管理方針

### ビルド・バンドル

**ロックファイルの管理**:
- `package-lock.json` (Node.js)
- `pom.xml` + `maven.lock` (Java/Maven)
- `requirements.txt` + `Pipfile.lock` (Python)

すべてのロックファイルはバージョン管理に含める。

### ライブラリ

#### 選定・削除基準(禁止事項)

**禁止事項**:
-メンテナンスされていないライブラリ(最終更新が2年以上前)
- ❌ 既知の脆弱性があるライブラリ
- ❌ ライセンスが不明確なライブラリ
- ❌ 同じ機能の重複ライブラリ

**選定基準**:
- ✅ アクティブにメンテナンスされている
- ✅ 十分なダウンロード数・スター数がある
- ✅ ドキュメントが整備されている
- ✅ ライセンスがプロジェクトと互換性がある

#### バージョン指定方針

**推奨**: マイナーバージョンまで固定、パッチバージョンは自動更新

```json
// package.json の例
{
  "dependencies": {
    "express": "~4.18.0",  // 4.18.x の最新を許可
    "lodash": "4.17.21"     // 完全固定
  }
}
```

#### 更新・脆弱性管理

**定期更新**:
- 月次で依存関係の更新をチェックする
- セキュリティアップデートは即座に適用する

**脆弱性スキャン**:
```bash
# Node.js
npm audit

# Java (Maven)
mvn dependency-check:check

# Python
pip-audit
```

**自動化**:
- Dependabot / Renovate Bot によるPR自動作成
- CI/CDパイプラインでの脆弱性チェック

---

## 構成管理のワークフロー

```mermaid
graph TB
    A[開発者] --> B{変更の種類}
    B -->|コード変更| C[ブランチ作成]
    B -->|ライブラリ追加| D[依存関係更新]
    B -->|環境変数追加| E[設定ファイル更新]
    
    C --> F[コミット]
    D --> F
    E --> F
    
    F --> G[プルリクエスト]
    G --> H{レビュー}
    H -->|承認| I[マージ]
    H -->|却下| J[修正]
    J --> F
    
    I --> K[CI/CD実行]
    K --> L[アーティファクト作成]
    L --> M[リリース]
```

---

## 構成管理のチェックリスト

### 開発開始時
- [ ] リポジトリをクローンし、最新のコードを取得する
- [ ] 依存関係をインストールする(`npm install` / `mvn install`)
- [ ] 環境変数を設定する(`.env.local`を作成)
- [ ] ローカル環境で正常に起動することを確認する

### 変更時
- [ ] 適切なブランチで作業している
- [ ] 依存関係の変更がある場合、ロックファイルも更新する
- [ ] 環境変数の変更がある場合、`.env.example`も更新する
- [ ] コミットメッセージが規約に従っている

### リリース時
- [ ] バージョン番号を更新する
- [ ] CHANGELOGを更新する
- [ ] Gitタグを作成する
- [ ] アーティファクトをリポジトリにアップロードする
- [ ] 構成管理台帳を更新する

---

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


🏗️ プロセス1: バージョン管理方針の策定

設計対象:

ソースコード、設定ファイル、ドキュメントなどのバージョン管理システムとブランチ戦略を決定する。

具体例:

  • Git を使用し、GitHub / GitLab のどちらをホスティングサービスとして使うか
  • ブランチ戦略は Git Flow、GitHub Flow、Trunk-Based Development のいずれを採用するか
  • コミットメッセージの記述ルール(Conventional Commits など)を定めるか
  • プルリクエストのレビュー方針(必須レビュアー数、承認フローなど)をどうするか

設計原則:

  • チーム規模に応じた戦略選択: 小規模チームは GitHub Flow、大規模・複数リリースラインがある場合は Git Flow など、チーム構成に合わせる
  • シンプルさの優先: 過度に複雑なブランチ戦略は避け、チーム全体が理解・実践できるシンプルな方針にする
  • 自動化の推進: CI/CD との連携を前提に、自動テスト・自動デプロイが可能な構成にする
  • 履歴の保護: main/master ブランチへの直接プッシュを禁止し、プルリクエスト経由での変更のみを許可する

文書化の推奨表現:

  • ブランチモデルの図示: 採用したブランチ戦略を図で示し、各ブランチの役割と運用フローを明確にする
  • 運用ルールの明文化: コミットメッセージ規約、プルリクエストの作成・レビュールール、マージ方針を記載する
  • 権限設定の記録: リポジトリへのアクセス権限、保護ブランチの設定を文書化する
🏗️ プロセス2: バージョニングとリリース管理方針の策定

設計対象:

システムのバージョン番号の付与方法、リリースタグの管理、構成管理台帳の運用方法を決定する。

具体例:

  • セマンティックバージョニング(MAJOR.MINOR.PATCH)を採用するか、日付ベース(YYYY.MM.DD)にするか
  • リリース時のタグ命名規則(v1.0.0、release-1.0.0 など)をどうするか
  • リリース候補(RC)やプレリリース版の扱いをどうするか
  • 構成管理台帳にどの情報を記録するか(バージョン、リリース日、コミットハッシュ、担当者など)

設計原則:

  • 業界標準の採用: セマンティックバージョニングなど、広く認知された方式を採用し、理解しやすくする
  • 追跡可能性の確保: すべてのリリースにタグを付与し、構成管理台帳で履歴を管理する
  • 自動化の検討: バージョン番号の更新、タグの作成、CHANGELOG の生成を自動化できる仕組みを検討する

文書化の推奨表現:

  • バージョニングルールの定義: バージョン番号の付与ルール、インクリメント条件を明確に記載する
  • 構成管理台帳のフォーマット: 記録すべき項目とテンプレートを定義する
  • リリースプロセスの記述: リリース時の手順(バージョン更新→タグ作成→ビルド→台帳更新)を明確にする
🏗️ プロセス3: 依存ライブラリ管理方針の策定

設計対象:

外部ライブラリの選定基準、バージョン管理方法、更新・脆弱性対応の運用方針を決定する。

具体例:

  • ライブラリのバージョン固定方針(完全固定、パッチバージョン自動更新など)をどうするか
  • ロックファイル(package-lock.json、pom.xml など)をバージョン管理に含めるか
  • 脆弱性スキャンツール(npm audit、Dependabot など)をどう活用するか
  • ライブラリの更新頻度(毎月、四半期ごとなど)とレビュープロセスをどうするか
  • 使用禁止ライブラリ(メンテナンス停止、ライセンス問題など)のリストを作成するか

設計原則:

  • 安定性とセキュリティの両立: 最新版を追いすぎず、かつ脆弱性を放置しないバランスの取れた更新方針にする
  • 再現性の保証: ロックファイルを必ずバージョン管理に含め、すべての環境で同じバージョンを使用できるようにする
  • 定期的なメンテナンス: 依存ライブラリの更新を定期的にレビューし、技術的負債を蓄積させない
  • ライセンスコンプライアンス: 使用するライブラリのライセンスを確認し、プロジェクトと互換性があることを保証する

文書化の推奨表現:

  • 選定基準の明文化: ライブラリ採用時のチェック項目(メンテナンス状況、ダウンロード数、ライセンスなど)を列挙する
  • バージョン管理ポリシー: パッケージマネージャごとのバージョン指定方法と推奨設定を記載する
  • 更新プロセスの定義: 定期更新のタイミング、脆弱性対応の緊急度判定基準、レビューフローを記述する
🏗️ プロセス4: 環境変数・秘密情報管理方針の策定

設計対象:

環境ごとに異なる設定値や秘密情報(パスワード、APIキーなど)の管理方法を決定する。

具体例:

  • 環境変数をどこで管理するか(.env ファイル、AWS Parameter Store、Secrets Manager など)
  • 環境変数をどう分類するか(公開情報、環境依存情報、秘密情報)
  • 秘密情報をソースコードに含めないためのチェック方法(git-secrets、pre-commit hooks など)
  • 各環境(ローカル、開発、ステージング、本番)での環境変数の設定方法

設計原則:

  • 秘密情報の厳格な保護: パスワードや API キーは絶対にソースコードに含めず、専用の管理システムで保護する
  • 環境ごとの分離: 開発環境と本番環境で異なる設定値を使い分け、誤操作を防ぐ
  • アクセス制御: 秘密情報へのアクセス権限を必要最小限に制限し、監査ログを残す

文書化の推奨表現:

  • 環境変数の分類表: 各環境変数を公開/環境依存/秘密の3つに分類し、管理方法を明記する
  • 管理ツールの選定理由: 採用した管理システム(Parameter Store など)の選定理由と使用方法を記載する
  • セキュリティガイドライン: 秘密情報の取り扱いルール、漏洩時の対応手順を明確にする

🚨 よくある失敗と予防策 


🚧 実例収集後、追記予定

📚 参考資料・関連リンク


  • 参考文献: 『Git によるバージョン管理』、『セマンティックバージョニング 2.0.0 仕様』、『継続的デリバリー』
  • 関連する他のガイド: CI/CD 設計ガイド、リリース管理ガイド、セキュリティ設計ガイド
  • ツール・テンプレート:
    • Git / GitHub / GitLab
    • Dependabot / Renovate Bot(依存関係自動更新)
    • npm audit / Snyk(脆弱性スキャン)
    • AWS Parameter Store / Secrets Manager(秘密情報管理)


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