Anti Patterns of Local Build / Private Build

Local Build is a very important practice in Agile which helps in getting sucessful build more frequently. To get more details about what is Local Build you may refer to the previous post:
http://thinkinginagile.blogspot.com/2011/07/private-build-local-build.html
However due to lack of awareness, process or discipline and due to other infrastucture issues there are some anti patterns to Local Build which is furnished below:

• Running all the test cases in the Local Build- Developer runs the functional / integration test cases (typically that takes long time) as part of the local build.


• Running all kinds of Inspection tools in Local Build- Developer runs all the inspection tools like Static Code Analyzer, Test Static Code Analyzer, Simian for Duplicate Code analysis, Useless code detector, Code Complexity Measurement tool etc. ( Just running the static code for the source code is enough. For the detailed feedback anyway the mainline build is there. However if there is a trend seen where the check-in often breaks due to issues from other tools, then the team should focus on competency improvement and ensure that all members are trained well to write good code and test code. It is not advisable to add so many inspection tools to the Local Build as it consumes more time.)


• Unit Test Cases ,in reality is not Unit level cases- 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 entities like databases, which increases the time it takes to setup and run tests.


• Test Suite Organization Structure not followed well- Sometimes it is seen that the way the test cases are organized , it is difficult to identify the unit test cases separately. When deeply analyzed, it is found that the team does not have any protocol to follow naming convention to identify the test suite and test cases for the test type.


• Not using the same directory structure as configuration Library- 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 :

• IDE does not support a one click Local Build - 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)



• Local build takes more than 3-5 minutes for providing result- I have seen sometimes Local / Private Build takes around 30 minutes to run and the developer has to wait to get the feedback and he /she sits idle. It creates productivity dip and the motivation level of developer is less to run local build every time.



• Developer PC is not of good configuration- Developer PC configuration is not good due to which Local Build takes more time.



• Members taking short cuts- Sometimes the team members in hurry takes short cuts. If this is not addressed, it becomes a culture and later correcting this becomes an issue. Running Local Build is a healthy practice and it is more of a culture.