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 6 February 2013

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