1. Integrating the Code during the Development Alexander Vakrilov Telerik Corporation www.telerik.com

2.  Faster bug detection  Less bugs  Improved code quality  Shorter release cycle  Accurate status quo  Better customer relations  Improved morale 2 Source: http://news.bbc.co.uk/cbbcnews/hi/newsid_6410000/newsid_6411100/6411145.stmhttp://news.bbc.co.uk/cbbcnews/hi/newsid_6410000/newsid_6411100/6411145.stm

3. Phased or Incremental Source: http://www.dpchallenge.com/image.php?IMAGE_ID=303123http://www.dpchallenge.com/image.php?IMAGE_ID=303123

4.  Steps  Develop unit by unit  Combine all units into the big system  Test and debug the whole system  Hope everything will work together 4

5.  Phased integration comes late to the project  Problems might come from every unit or from combination of some units  Some typical problems:  Shared global state  Weak encapsulation  Poorly documented interfaces 5

6.  Integrate one unit at a time  Steps  Start with a small functional part of the system. It will a skeleton for the project  Develop a single unit (code, test, debug…)  Integrate the unit into the skeleton and verify its behavior 6

7.  Errors surface immediately  You always have something working  Better customer relations  Improved team confidence  Improved progress monitoring  More robust unit testing  Shorter development schedule 7 Source: http://www.flickr.com/photos/mcbeth/2224754533/http://www.flickr.com/photos/mcbeth/2224754533/

8. Integrate “your way” Source: http://www.flickr.com/photos/benheine/3529694787/http://www.flickr.com/photos/benheine/3529694787/

9.  Write classes on the top of the hierarchy first  Main Module / Main Window first  Benefits:  Control flow logic is tested early on  Conceptual problems are exposed quickly  Postpone design of low-level details  Disadvantages  Tricky integration parts are exposed last  There maybe no top component  Requires large number of stubs 9 Source: http://www.flickr.com/photos/mareknim/2414682400/http://www.flickr.com/photos/mareknim/2414682400/

10.  Write classes on the bottom of the hierarchy first  Benefits:  Troublesome low level integration problems are found quickly  Disadvantages  The big picture is blurry  High level integration starts later on  The whole system before must be designed before you start integration. 10 Source: http://www.flickr.com/photos/darijuss/2020975929/http://www.flickr.com/photos/darijuss/2020975929/

11.  Steps  Write classes on the top of the hierarchy first  Write low level integration pieces after that  Write middle level components last  Benefits:  Combines benefits of both top-down and bottom-up approaches 11 Source: http://www.flickr.com/photos/_sk/2891543025/http://www.flickr.com/photos/_sk/2891543025/

12.  Steps  Identify problematic (risky) areas  Start from most difficult and uncertain parts first  Benefits:  Problematic areas are exposed early on  Disadvantages  Initial progress is slow 12 Source: http://www.flickr.com/photos/7308152@N07/3168909738/http://www.flickr.com/photos/7308152@N07/3168909738/

13.  Steps  Develop one feature at a time  Integrate this feature back to the skeleton when its done  Benefits:  Removes scaffolding  Progress monitoring  Works well with Object-Orientation 13 Source: http://www.flickr.com/photos/robdurfee/181881853/http://www.flickr.com/photos/robdurfee/181881853/

14.  All mention approaches have benefits and draw back  Use what works for you and your team for this specific project  Don’t be afraid to mix and match them  Golden mean is the key to success 14 Source: http://www.flickr.com/photos/blix613/2680646992/http://www.flickr.com/photos/blix613/2680646992/

15. Keep your project healthy Source: http://www.flickr.com/photos/_mad_/2963537283/http://www.flickr.com/photos/_mad_/2963537283/

16.  Code is checked-in to the source repository  A build is triggered on a separate build machine  Source is compiled and tests are executed  The build either succeeded or failed 16 Source: http://www.flickr.com/photos/hindrik/3331515368/http://www.flickr.com/photos/hindrik/3331515368/

17.  Build is healthy all the time  Easy defect diagnostics and bug hunting  Constant availability of a "current" build for testing, demo, or release purposes  Early warning of broken/incompatible code 17 Source: http://www.guidespark.com/blog/wp- content/uploads/2010/06/Financial-Health_Small.jpg http://www.guidespark.com/blog/wp- content/uploads/2010/06/Financial-Health_Small.jpg

18.  Build often  Fixing a broken build is top priority  Create a penalty for breaking the build  Tests are part of the build  Automate the CI Build as much as possible 18 Source: http://www.flickr.com/photos/iancowe/4254566515/http://www.flickr.com/photos/iancowe/4254566515/

19.  Establish a build group  Do CI at any cost, even under pressure  Setup a nightly build 19 Source: http://www.flickr.com/photos/asbo_allstar/3831718858/http://www.flickr.com/photos/asbo_allstar/3831718858/

20. Questions? http://academy.telerik.com