Hybrid Branching Strategy for Risk Management
After implementing both pure GitFlow and trunk-based approaches across multiple teams, I’ve found that a hybrid model provides the best risk visibility in Rally while maintaining development velocity.
The Core Problem
Traditional branching strategies create a mismatch with modern risk management:
- GitFlow: Clear branch-based separation but creates integration delays and fragmented risk tracking across long-lived branches
- Trunk-based: Fast integration but obscures release readiness and makes pre-merge risk assessment difficult
Both approaches fail when risk evaluation needs to happen independently of code integration timing.
Hybrid Branching Architecture
The solution is to separate three concerns that traditional branching conflates:
1. Code Integration (Trunk-based)
- Main branch is the single source of truth
- Feature branches are short-lived (< 2 days)
- Merge frequency is high (multiple times daily)
- Continuous integration runs on every merge
2. Risk Assessment (Portfolio-based)
- Rally risk portfolios map to deployment stages, not branches
- Each portfolio has explicit entry/exit criteria
- Risk evaluation happens asynchronously from merge events
- Stories can be “integrated but not released”
3. Release Control (Environment Gates)
- Four-stage promotion pipeline: Dev → Staging → Pre-Prod → Production
- Each gate requires Rally portfolio approval
- Automated gates for technical criteria (tests pass, security scan clean)
- Manual gates for business risk (compliance review, stakeholder sign-off)
Tag-based Tracking Implementation
Tags become the integration point between git and Rally risk portfolios:
Sprint Tags: Automatically created on main branch
- Format:
sprint-YYYY-Wnn-nnn (e.g., sprint-2025-W43-001)
- Each tag links to Rally milestone via webhook
- Risk portfolio queries Rally for all stories in milestone
- Provides sprint-level risk aggregation
Release Tags: Manually created for production deployments
- Format:
release-YYYY.MM.nn (e.g., release-2025.10.03)
- Bundles multiple sprint tags into a release candidate
- Rally release portfolio aggregates risk across all included sprints
- Immutable - once created, risk assessment is locked
Feature Tags: Optional for large initiatives
- Format: `feature-{name}-checkpoint-nn
- Used for multi-sprint features requiring interim risk reviews
- Rally tracks feature-level risk across multiple releases
Risk Portfolio Configuration
Rally portfolios map to pipeline stages:
Development Portfolio
- Includes: All stories merged to main in current sprint
- Risk Level: Low oversight - automated checks only
- Exit Criteria: CI passes, unit tests green, no critical defects
Staging Portfolio
- Includes: Stories promoted from dev, tagged for staging deployment
- Risk Level: Medium oversight - integration testing required
- Exit Criteria: Integration tests pass, performance benchmarks met, security scan clean
Pre-Production Portfolio
- Includes: Stories approved for production consideration
- Risk Level: High oversight - compliance and business risk review
- Exit Criteria: Risk assessment complete, compliance approval, stakeholder sign-off
Production Portfolio
- Includes: Stories deployed to production
- Risk Level: Post-deployment monitoring
- Exit Criteria: Monitoring shows no incidents, rollback plan validated
Each portfolio has a corresponding Rally dashboard showing risk metrics, blocking issues, and approval status.
Environment Gates Process
Gates enforce risk criteria before promotion:
-
Dev Gate (Automated)
- Triggered by merge to main
- Deploys to dev environment automatically
- Updates Rally story status to “In Development Environment”
-
Staging Gate (Semi-Automated)
- Requires manual promotion trigger
- Validates all stories in sprint tag have passed dev criteria
- Creates staging deployment tag
- Updates Rally staging portfolio
-
Pre-Prod Gate (Manual Approval)
- Requires risk assessment completion in Rally
- Compliance team reviews risk portfolio
- Business owners approve feature set
- Only proceeds if Rally portfolio status = “Approved”
-
Production Gate (Release Manager)
- Final manual approval by release manager
- Validates production readiness checklist in Rally
- Creates immutable release tag
- Updates Rally production portfolio
If any gate fails, the story remains in the previous portfolio until issues are resolved. This provides clear risk visibility - you always know which environment each feature has reached and what’s blocking further promotion.
Handling Feature Rollback
The hybrid model handles rollback scenarios gracefully:
Scenario 1: Risk Assessment Fails Pre-Production
- Code remains in main branch (already integrated)
- Feature flag keeps it disabled in production
- Rally portfolio shows “Risk Review Failed” status
- Story moves back to staging portfolio for remediation
- No git operations required
Scenario 2: Production Issues Require Immediate Rollback
- Feature flag disabled in production (immediate)
- Rally production portfolio updated to “Rolled Back” status
- Revert commit created and tracked in Rally
- Post-mortem linked to story for risk analysis
Scenario 3: Feature Removed from Release
- Remove feature tag from release bundle
- Rally release portfolio automatically recalculates risk without that feature
- Feature remains in pre-prod portfolio for future release
- Code stays in main - no cherry-picking required
Benefits Over Pure Approaches
This hybrid model provides:
- Velocity: Trunk-based integration speed without sacrificing risk control
- Visibility: Clear risk status at every pipeline stage
- Flexibility: Features can be evaluated and promoted independently
- Compliance: Full audit trail of risk decisions in Rally
- Rollback Safety: Multiple rollback mechanisms (flags, reverts, promotion blocks)
The key insight is that risk management should be orthogonal to branching strategy. By using Rally portfolios and environment gates as the risk control layer, you can adopt trunk-based development for velocity while maintaining rigorous risk governance.