Blog Date: 1/13/2009
Several methodologies were born in the 1990s as alternative approaches to process intensive development models like the Rational Unified Process (RUP). Some developers felt that these models did not represent the dynamic nature of software development where priorities often change and user feedback is critical. Through experience, many development teams recognized that software projects are built in many shapes and sizes, and that heavyweight software methodologies do not fit in many cases, especially for smaller, more dynamic development efforts. The predictive waterfall methodology, for example, does not scale well for rapidly changing development environments.
The extreme programming, adaptive software development, and Dynamic Systems Development Method (DSDM) methodologies were all created to allow project management and developers to adapt to change quickly without sacrificing quality. In retrospect, it was clear that these methodologies had many common themes, such as the ability to respond quickly to customer feedback and business demands, an understanding that customers have a strong voice in how the product evolves, short development iterations, and full testing coverage. Development teams began adopting the methodology that was the best fit for their organization and fed improvements back to evolve the methods over time.
In 2001, a group of wise software professionals convened to discuss commonality among these methodologies—a meeting of the "five families" of adaptive software development. These software professionals coined the term "agile" to encompass all that was in common among the methodologies.
Since that time, agile development has grown and tools have been created to help. Meanwhile, development teams are reaping the benefits. Unit testing tools like NUnit have become integral parts of the development process. Likewise, continuous integration has become a standard practice that many development teams have adopted even without fully adopting an agile methodology.
Continuous Integration and Test-Driven Development (TDD)
Extreme programming in particular emphasizes TDD, a natural fit into continuous integration. TDD proposes that the developer write a test case (typically a unit test), write the code exercised by that test, run the automated test, and refactor the code as necessary. Writing these tests effectively yields unit tests that give adequate test coverage across the product. These automated tests are placed in a common area where all developers and testers have access to run them before checking any code into the build.
This fits in well with continuous integration because, after a build is compiled, all unit tests are run on the latest build. If any unit test fails, then the build fails because something is not working properly. It is very important that the test cases cover as much of the product as possible to ensure a quality product. Another good practice is to produce unit tests for bugs that are fixed so that bugs can be verified and checked on an ongoing basis in an automated way.
One obvious benefit of continuous integration is transparency. Failed builds and tests are found quickly rather than waiting for the next build. The developer who checked in the offending code is probably still nearby and can quickly fix or roll back the change. If test cases are plentiful and thoughtfully composed, there are fewer burdens on quality assurance (QA) resources to find latent bugs, which gives you peace of mind regarding software quality. The result is more time for developing features and refactoring and less time spent trying to find integration errors.
To create unit tests and continuous integration I personally use Visual Studio 2008 (It is also possible with VS2005) Team System and Team Foundation Server. It is also possible to implement continuous integration without these tools. CruiseControl.NET is another example of a tool you can employ to implement continuous integration for your projects.
http://msdn.microsoft.com/en-us/magazine/cc188695.aspx
1/13/2009 11:38:29 AM