Prezi

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in the manual

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Efficient Build Promotion

No description
by Hans Dockter on 20 September 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Efficient Build Promotion

Continuous Delivery with
Large Software Stacks

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