パッケージリリース戦略¶
基本概念¶
ブランチ戦略: main + feature/* のみ
- main: 常にリリース可能な安定版
- feature/*: 機能開発後、直接mainにマージ
- 複雑なブランチ管理は排除
トリガー: release-x.y.z タグのプッシュ、またはGitHub Actionsの手動実行
- タグ作成・プッシュで本番リリース
- GitHubのUIからワークフローを手動実行した場合はテストリリース
- いずれもバージョンは自動発番
- 手動判断でリリースタイミングを完全制御
リリースフローの概念¶
1. 開発サイクル¶
feature開発 → mainマージ → 蓄積 → リリース判断 → タグ作成 or 手動実行
個人開発では「いつリリースするか」を自分で判断。複数のfeatureを蓄積してからまとめてリリースも可能。
2. 自動化されるリリースプロセス¶
タグ検知 or 手動実行 → バージョン自動検出 → ビルド → 配布 → Release作成
- バージョン管理: setuptools_scmがGitタグやコミットから自動的にバージョン番号を検出
- パッケージビルド: Pythonパッケージ（wheel, tarball）を生成
- PyPI公開: タグ作成時はPyPI、本番用に自動アップロード。手動実行時はTestPyPI（https://test.pypi.org/）にアップロード
- GitHub Release: タグに対応するReleaseを自動作成し、ビルド成果物を添付（本番リリース時のみ）
3. 成果物の流れ¶
ソースコード → Pythonパッケージ（.whl, .tar.gz） → PyPIまたはTestPyPI + GitHub Release添付
PyPI: パッケージの配布場所（pip installで取得）
TestPyPI: テスト用パッケージ配布場所（pip install --index-url https://test.pypi.org/simple/ ...）
GitHub Release: プロジェクトの公式リリース記録 + パッケージファイルのバックアップ（本番リリース時のみ）
setuptools_scmによるバージョン管理¶
設定:
[build-system]
requires = ["setuptools>=64", "setuptools_scm>=8"]
build-backend = "setuptools.build_meta"
[project]
dynamic = ["version"]
[tool.setuptools_scm]
# Gitタグやコミットから自動的にバージョンを取得
バージョニング戦略¶
セマンティックバージョニング (x.y.z)
- Major（x）: 破壊的変更、API非互換
- Minor（y）: 新機能追加、後方互換
- Patch（z）: バグ修正
個人開発での判断基準: - 日常的な機能追加 → Minor - 小さな修正・改善 → Patch - 設計の大幅変更 → Major
運用の要点¶
開発者の作業¶
- feature開発・mainマージ（通常の開発）
- リリース準備（テスト実行、動作確認）
- タグ作成・プッシュ または GitHub Actionsの手動実行（唯一の手動リリース操作）
自動化範囲¶
- setuptools_scmによるGitタグやコミットからの自動バージョン検出
- パッケージビルド・検証
- PyPIまたはTestPyPI公開
- GitHub Release作成・成果物添付（本番リリース時のみ）
- 基本的なエラーハンドリング
品質保証¶
- mainブランチでの継続的テスト（PR時・プッシュ時）
- リリース時のビルド検証
- バージョン形式の検証
戦略の利点¶
シンプルさ: ブランチ管理最小限、理解しやすいフロー 制御性: リリースタイミングを完全に自分で決定 自動化: 手動作業は「タグ作成」または「ワークフロー手動実行」のみ、ファイル変更不要 可視性: GitHub Releasesで公式リリース履歴を管理 配布: PyPI経由で標準的なPythonパッケージとして配布、TestPyPIで事前検証も可能 整合性: Gitタグやコミットが唯一の真のバージョン情報源
この戦略により、個人開発でも本格的なパッケージ配布が可能になり、後の拡張性も確保できます。