リリース自動化の嬉しみとその手法

ブランチ戦略

リリースブランチを常時リリース可能状態にする
- デフォルトブランチやリリースブランチが「常時リリース可能」であることを前提としている場合が多い
- もしブランチが常時リリース可能でなかったら、リリース作業前に「リリース可能かどうか」を人間が検証する必要性が出てしまう
- リリース可能性検証のプロセスを自動化して、マージ前ビルドないしリリースビルドで自動的に検証されるようにする
「マージしたらリリースされてしまう」ことを「完成するまでマージするべきではない」と受け止めないことも必要
- トピックブランチの寿命は短いほうが開発効率に良い影響がある。リリースできないとわかっている変更は公開することは避けつつ高頻度に変更をマージするためにFeature flugなどの工夫をする

Base Patterns
- Source Branching
- Mainline
- Healthy Branch -> 各コミットに対しテスト実行などで自動チェックし、ブランチに欠陥がないことを確認する
Integration Patterns
- Mainline Integration
- Feature Branching
- Integration Frequency
  - Low-Frequency Integration
  - High-Frequency Integration
  - Comparing integration frequencies
- Continuous Integration
- Comparing Feature Branching and Continuous Integration -> 統合の頻度が高いほど、統合の関与が少なくなり、統合への恐怖が少なくなる
  - Feature Branching and Open Source
- Pre-Integration Review
- Integration Friction
- The Importance of Modularity
- Personal Thoughts on Integration Patterns
The path from mainline to production release
- Release Branch
- Maturity Branch
  - Variation: Long Lived Release Branch
- Environment Branch
- Hotfix Branch
- Release Train
  - Variation: Loading future trains
  - Compared to regular releases off mainline
- Release-Ready Mainline
Other Branching Patterns
- Experimental Branch
- Future Branch
- Collaboration Branch
- Team Integration Branch
Looking at some branching policies
- Git-flow
- GitHub Flow
- Trunk-Based Development
- Final Thoughts and Recommendations

リリース可能状態が担保されたメインラインへ頻繁にマージしていくのが良い。そのために、リリース見込みが経っていないものについては、

リリースするものについては、