Your SlideShare is downloading. ×
Starting Fresh Every Morning
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Starting Fresh Every Morning

679
views

Published on

These are the slides for the presentation I gave at ESUG 2008, on Continuous Integration in Kapital (the risk management system I work on at J.P. Morgan)

These are the slides for the presentation I gave at ESUG 2008, on Continuous Integration in Kapital (the risk management system I work on at J.P. Morgan)

Published in: Business, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
679
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Starting fresh every morning Building a new development image every morning
  • 2. $> whoami
  • 3. What We Are Talking About
  • 4. What We Aren’t Talking About
  • 5. Introducing the Beast Kapital has been actively developed since  1995 Kapital has more than 22000 classes  (VW with ENVY has 2200) Kapital is more than 70 developers pushing  changes everyday! Every development cycle we change 5000  classes Each day, we change from 60 to 150 classes 
  • 6. Why Change My Image ? Resynchronizing the code base with the other  developers Avoiding important splits from the main branch  Checking prerequesites  Avoiding unknown dependencies 
  • 7. Why Change My Image ? Resynchronizing the code base with the other  developers Avoiding important splits from the main branch  Checking prerequesites  Avoiding unknown dependencies 
  • 8. Resynchronizing the Code Base The sooner you merge, the better  Everyday, 60 to 150 classes are changed  Everyday, 25 change sets are applied  Average size of a change set = 5-8 classes  25*5 = 125  25*8 = 200  Avoiding multiple implementations for a single  piece of functionality
  • 9. Why Change My Image ? Resynchronizing the code base with the other  developers Avoiding important splits from the main branch  Checking prerequesites  Avoiding unknown dependencies 
  • 10. Avoiding Important Splits Decompose code changes into smaller, more  manageable steps
  • 11. Why Change My Image ? Resynchronizing the code base with the other  developers Avoiding important splits from the main branch  Checking prerequesites  Avoiding unknown dependencies 
  • 12. Checking Prerequisites Always make ENVY happy  
  • 13. Why Change My Image ? Resynchronizing the code base with the other  developers Avoiding important splits from the main branch  Checking prerequesites  Avoiding unknown dependencies 
  • 14. Avoiding Unknown Dependencies #{MyClassOrGlobalVariable} ifDefinedDo: [ :thing | thing doStuff]. THIS IS NOT GOOD !!!
  • 15. How We do it in Kapital Loading the top level map  Validating the build  A fresh image every time  Dangers of savedowns 
  • 16. Introducing ENVY/Developer Applications and configuration maps  Granularity = methods (class,  application, config map) Great flexibility (ENVY boy talking ) 
  • 17. How We do it in Kapital Loading the top level map  Validating the build  A fresh image every time  Dangers of savedowns 
  • 18. Loading the Top Level Map Kapital benefits from base ENVY  functionality BEWARE! ENVY is known to bite  developers!
  • 19. How we do it in Kapital Loading the top level map  Validating the build  A fresh image every time  Dangers of savedowns 
  • 20. Validating the build Two types of testing systems  Code driven = specific code items (SUnit  style) Data driven = end-to-end testing  (“SmokeTest”)
  • 21. How we do it in Kapital Loading the top level map  Validating the build  A fresh image every time  Dangers of savedowns 
  • 22. A fresh image every time Always ensure your code loads in a  fresh image Of course, there are times where the  image is wrong
  • 23. How We do it in Kapital Loading the top level map  Validating the build  A fresh image every time  Dangers of savedowns 
  • 24. Dangers of Savedowns Building an image is great but…  IT TAKES TIME!
  • 25. Breaking the Build … It will happen!  Don’t let the build process become a  burden It’s nothing more than a failing sanity  check
  • 26. … Identifying the Issue … 3 types of failures  Successful build, but failing tests  Uncompleted build  Successful build, but failed load 
  • 27. … Identifying the Issue … 3 types of failures  Successful build, but failing tests  Uncompleted build  Successful build, but failed load 
  • 28. Successful Build, but Failing Tests Is your code wrong ?  Is your data wrong ? 
  • 29. … Identifying the Issue … 3 types of failures  Successful build, but failing tests  Uncompleted build  Successful build, but failed load 
  • 30. Uncompleted Build This is Smalltalk, you can debug  Find the offending code change first  Typically it’s a prerequisite issue. A  method not yet introduced, a class (or variable) not yet declared
  • 31. … Identifying the Issue … 3 types of failures  Successful build, but failing tests  Uncompleted build  Successful build, but failed load 
  • 32. Successful Build, but Failed Load The code didn’t load all the way  Revealed by the tests run on the image  (missing code) Know your SCM system well!  ENVY does this for overrides 
  • 33. … And Fixing the Build! Always find the error before fixing it  You must fix the build before you can  validate today’s code base
  • 34. … And Fixing the Build! (2) 3 types of errors can be introduced by  code changes: Calling a method not yet present  Depending on code not yet released  Clashing code 
  • 35. … And Fixing the Build! (2) 3 types of errors can be introduced by  code changes: Calling a method not yet present  Depending on code not yet released  Clashing code 
  • 36. Calling a Method Not Yet Present
  • 37. … And Fixing the Build! (2) 3 types of errors can be introduced by  code changes: Calling a method not yet present  Depending on code not yet released  Clashing code 
  • 38. Depending on Code Not Yet Released
  • 39. … And Fixing the Build! (2) 3 types of errors can be introduced by  code changes: Calling a method not yet present  Depending on code not yet released  Clashing code 
  • 40. Clashing Code a.k.a mismerged code  Because some classes are centers of  high activity
  • 41. Questions ? yann@monclair.fr