Build – by definition is to compile all the source code of a project and create the deliverables. For example, build is to compile all Java code using ant or maven and then create the executable jar files or war files or ear files.
An effective build system goes long way to help the project. Nightly or at least weekly development build bits are essential to check the status of the project. Lets divide build systems in its effectiveness.
Step 0 – Build system checks the syntax errors. This is really basic and a must do for build systems. If there is a syntax error in any code , build should fails. It usually does as the compiler stops if there is a syntax error.
Step 1 – Build fails if the unit test fails on the code. This is where most of current projects are. Build fires the compilation, followed by creation of deployable jars/wars. As the last step, build fires the JUnit test cases. If the JUnit test case fails, build breaks. This makes sure the build output is sane and no unit test cases have failed on the build output.
Step 2 – Now lets consider of a build system which breaks if the code checkin has more complexity than the standard, or if the code coverage of the code checkin is less. There are several software metrics that are available now, like “Code Coverage”, “Cyclomatic complexity of code”, “CRAP Metric (Change Risk Analyzer and Predictor)”. [ there are already plugins available on the CRAP and Cyclomatic Metric, where can be found here]
If Build system is integrated with calculation of these metrics, that would guarentee a uniform code complexity and if anytime code complexity numbers come high from the code analysis tools, build should break. This is surely a cool thing to do considering the fact that now-a-days much of the code is getting auto generated. Example, you have a webservice which was using Framework version 1 {like axis1} and you were compiling WSDL file to generate the stub code. You move to Version 2 and build breaks because the auto generated code is more complex and hard to maintain.
It should be a collective decision of the project team whether to go for higher complexity of the code as a team.
This is where at Step2, I think the next generation build systems will go.
