Git へのソース取り込みとブランチ戦略
分離・検証が完了したソースコードはまず Git 管理下に置きます。この時点が「ソース管理の起点」になります。
cd project-root
# .gitignore を作成（コンパイル成果物を除外）
cat > .gitignore <<'EOF'
*.o
*.so
*.exe
*.lst
test/output_*.dat
EOF
git init
git add src/ copybook/ jcl/ test/
git commit -m "feat: COBOLモジュール分離完了 — 初期ソース登録
分離元: YOURLIB.LOADLIB(YOURMOD)
検証: 入出力比較テスト PASS (正常系・境界値・異常系)
環境: IBM Enterprise COBOL V6.3 / z/OS 2.4"ブランチ戦略の推奨は以下の通りです。
| ブランチ | 用途 |
|---|---|
main | 検証済みのソース（現行相当）を保持。直接コミットしない。 |
modernization/java | Java 移植・API 化の作業用ブランチ。 |
fix/YYYYMMDD-issue | 緊急改修用。main からブランチして PR でマージ。 |
モダナイゼーションへの接続
分離されたソースコードをベースに、次のモダナイゼーション工程に進みます。
| 移行パターン | 概要 | ポイント |
|---|---|---|
| Java 移植 | COBOL のバッチ処理・業務ロジックを Java で再実装する。 | COBOL の固定長・PACKED DECIMAL を Java の型にどうマッピングするかが課題。分離済みソースを仕様書代わりに使う。 |
| REST API 化 | COBOL の CALL インターフェースを HTTP API でラップする。 | 短期移行として COBOL をそのまま残し API 層だけを追加するアプローチ。Spring Boot + JNI または GnuCOBOL の C API を使う。 |
| クラウド移行 | オンプレのメインフレームから AWS / Azure 上の Linux 環境へ移行する。 | GnuCOBOL でリコンパイルできる状態になっていれば ECS / EC2 へのリフト&シフトが可能。 |
💡 移行前の SonarQube 解析を推奨
分離済みソースコードを SonarQube（COBOL プラグイン）で解析すると、コード重複・未使用変数・複雑度の高い段落が可視化されます。移植範囲の絞り込みとリスク評価に活用できます。
作業記録をドキュメントとして残す
分離作業で得た知識は将来の改修・移植担当者にとって貴重な資産です。最低限以下の内容をドキュメント化してください。
# COBOL モジュール分離作業記録
## 対象モジュール
- 分離元: YOURLIB.LOADLIB(YOURMOD)
- コンパイラ: IBM Enterprise COBOL V6.3
- 環境: z/OS 2.4
## 分離結果
| ファイル | PROGRAM-ID | 役割 | 備考 |
|----------|------------|------|------|
| ORDMAIN.cbl | ORDMAIN | 受注メイン処理 | CALL ORDSUB01, ORDSUB02 |
| ORDSUB01.cbl | ORDSUB01 | 受注バリデーション | |
| ORDSUB02.cbl | ORDSUB02 | 受注登録 | DB2 EXEC SQL あり |
## コピーブック一覧
| ファイル | 参照元 | 内容 |
|----------|--------|------|
| ORDSTRC.cpy | ORDMAIN, ORDSUB01 | 受注レコード構造 |
## 制約・注意事項
- ORDSUB02.cbl は EXEC SQL を含む。再コンパイル時は DB2 プリプロセッサが必要。
- 最適化レベルは -O0 で検証済み。本番は -O2 でビルドすること。
## 検証結果
- 再コンパイル: ✅ エラーゼロ
- 入出力比較テスト: ✅ 全件一致（正常系20件・境界値5件・異常系3件）