Best Practices?
Don't care
Structure
Build
Promotion
Binary Snapshots
Local Build checks upstream
Quite a few jobs and build to manage
No local downstream check
- Possibly many breakages
- Feature Flow in Danger
- Exploratory Learning Difficult
Branching
Quite a few jobs and build to manage
Single Build
Problems with Feature Flow
- Separate Component Builds
- Separate VCS Repos
- Latest promoted
- Build is downstream aware
Large Project Example
Common Patterns
Water Gates
Facts
Continuous Delivery with
Large Software Stacks
The Good
The Bad?
- 500 devs
- Java & C++
- 15 years old legacy base
- 50 components
- 20 team
- Distributed
- One EAR
Practice
The Bad?
The Good
Our Focus:
- Build time 14-24 hours
- Always manage to compile
- 4 hours UI testing with frequent problems
- No strong local build
- Early Freeze
- Conservative Changes
Component Based Enterprise Apps
Hans Dockter
CEO, Gradleware
Founder Gradle
hans.dockter@gradleware.com
The Bad?
The Good
Criteria
Size of Code Base
CI Component Build
CI Full Build
Pre-commit Build
Commit Frequency
Team Relationships
Team Size
Developer Quality
Code Quality
- Builds promoted components
- Much more stable
- Good Feature Flow
- Uses promoted upstream
- Downstream aware
- Deeper Testing
- Promotes when successful
- Uses promoted upstream
- Downstream aware
- Contract Testing
- Needs to be fast
Reporting
Challenges
Performance
- Parallel & Distributed
- High level build avoidance
- Extremely Important
- Automation can't solve it all
- Integration Problems
- A statistical game
- RCA for build breakages
- Tests need to be good enough
- Automated infrastructure setup
- Potential resistance
- Breaking Changes
- Less CI pressure
- Model Cooperation Specifics
- Possibly many breakages
- Feature Flow in Danger
- Hard Exploration Learning