Private Build/ Local Build

Local Build comprises of process of compilation of the added source code and test code, running of the unit cases, running of the inspection tool especially the Static Code analyzer (Like PMD, Checkstyle, PCLint etc). We can also run functional test cases and more inspection tools like duplicate code detection tool like simian etc., but this may increase the time of feedback for the developer. So it is advisable to keep only the key aspects (compilation, unit testing, static code check) as part of private / local build.
Local Build process can be described in following steps :
Step 1- Developer finishes the task (coding, unit testing, integration and functional test)
Step 2: - Developer takes the latest code from the configuration management library which comprises of the latest code changes.
Step 3- Runs the Local / Private Build with the latest code.
Step 4- If the build passes, then commit is done to the configuration library. If the build fails then rework is done and step 1 onwards is repeated.

Below antscript shows how to run a Local or Private Build using Ant. This is just for reference. Actual Build Script need to be changed based on the project situation.

The Thumb Rule is that Local Build should be as fast as possible. It can be less than 3 minutes. The practice of Local Build can ensure that whenever the developer checks-in the code, he / she does not break the main-line build and always completes the work with good quality. Some of the commonly occuring anti patterns, which should be avoided while following the local build practice are as follows:

• Developer runs the functional / integration test cases (typically that takes long time) as part of the local build.


• Wrong understanding of Unit Testing. Test cases are categorized as unit test cases though it is not unit test cases. The key aspect of unit tests is having no dependency on outside aspects like databases, which increases the time it takes to setup and run tests.


• Some teams don't use good IDE that can support automated check-in from the IDE and taking the latest code from the configuration library.(Especially in C projects)


• Sometimes there is tendency to run all kind of test cases and also the inspection tools in the private build. This increases the execution time for local build.


• Not using the same directory structure as the configuration library due to which the environment and other aspects are not same. The typical directory structure for source code and test suite can be :
  
  
  This is also is one of the reason where the private build passes but the mainline build still fails.


• Developer Machine is not of good configuration and it takes long time to execute the local build.
  


• Taking Short-cuts. Lack of Discipline.

There is obviously no debate that Local Build Practice can bring lot of benefits to the team, if used effectively. It also compliments to the continuous integration practices. This practice can really ensure that the team is efficient and can deliver good quality with certainty.