Building software is like building a house in many ways. When building a house, we have to have a good foundation, strong pillars, proper plumbing and wiring, and so on and so forth. When building software, we need to have a good design, clear and concise code, proper wiring of components, etc.
There is one subtle difference between building software and building a house though. Usually when we build a house, we rarely make large renovations such as adding a story, moving around walls and windows, putting in a new electrical system, or modifying the foundation. Software, on the other hand, needs to be modified and updated quite often due to changes in business caused by Read more…
According to the 2009 CHAOS report published by the market research firm, the Standish Group, IT Project failure rate increased in the last 2 years of recession. No surprise.
According to the report the rate of successful projects that were delivered on-time, within budget, and with the required features, dropped from 35% in 2006 to 32% in the last two years. Also the rate of failed projects increased from 19% in 2006 to 24% recently, which included projects that were deemed complete failure and either never delivered, or delivered but never used. The rest of the projects were considered challenged, those that were delivered late, with incomplete features, or went significantly over-budget. Read more…
Traditionally, quality assurance ensures the quality of a product once it’s built in order to shield customers from receiving defective product. TQM suggests that rather than putting quality assurance at the end of the product cycle, feedback loops be placed at every step of the product building process so that the actual causes of defects can be identified and fixed. Fixing causes of defects can continually increase customer satisfaction at continually lowers costs.
Up until Visual Studio 2005 and .NET Framework 2.0, the actual build process of solution or project files was pretty much a black-box phenomenon for developers. With .NET Framework 2.0 and Visual Studio 2005, Microsoft unveiled its new build platform called MSBuild. MSBuild essentially provides a transparent build process through Visual Studio IDE, as well as allows developers to build projects and solutions from the command line. This allows us to fully customize our builds and create builds on machines where Visual Studio is not even installed.
On a recent team project I was using continuous integration or CI (an Agile practice) via CruiseControl.NET. It was a breeze to automatically build projects and solutions using MSBuild on our build server (a run-of-the-mill Dell workstation running Windows XP without Visual Studio 2005 installed) whenever someone checked-in any files to source control. This allowed us to be confident at all times that various pieces our distributed project integrate well. Moreover, since MSBuild can build projects and solutions from command line, I had some batch files setup that would build release versions of our projects, create setup files (using NSIS), archive older versions of setup files, and move new setup files to a network share where MIS / Operations folks could install the new version on the production server from.
In Visual Studio 2005, project and solution files are nothing more than MSBuild XML build scripts. This allows us full control over the build process. For example, in a web project, Visual Studio 2005 does not provide any user interface to modify pre and post build actions. However, since solution file is simply an MSBuild script, we can modify such actions manually by opening up the solution file in any text/XML editor.
MSBuild can perform several key tasks out of the box. Each task is essentially a unit of work (UOW) that contributes to the entire build process, e.g. copy files and folders, compile files, etc. If we ever require tasks that do not ship with MSBuild, we can always create custom tasks in any .NET language by simply implementing the ITask interface or deriving from the Task class.
In conclusion, MSBuild allows developers full control of the build process so that builds can be fully customized. This may not be so crucial in smaller projects, but for enterprise solutions that typically comprise of several projects and many dependencies, MSBuild is definitely a God-send!