Integrating the Code during the Development Alexander Vakrilov Telerik Corporation

 Faster bug detection  Less bugs  Improved code quality  Shorter release cycle  Accurate status quo  Better customer relations  Improved morale 2 Source:

Phased or Incremental Source:

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

 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

 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

 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:

Integrate “your way” Source:

 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:

 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:

 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:

 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:

 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:

 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:

Keep your project healthy Source:

 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:

 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: content/uploads/2010/06/Financial-Health_Small.jpg content/uploads/2010/06/Financial-Health_Small.jpg

 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:

 Establish a build group  Do CI at any cost, even under pressure  Setup a nightly build 19 Source:

Questions?