Continuous Integration during Agile Development Practices

Continuation integration is necessary in software development, and especially so in Agile frameworks...

"Continuous integration," a term coined by Martin Fowler and Kent Beck, refers to one of the best ways to improve productivity through automating a few tasks during development. Examples include automated pulling of the latest version of code, automated build, and automated execution of unit tests with immediate feedback to the users about the result obtained. Why is continuous integration required? We've often experienced programmers writing code and the task working perfectly, but later, while we integrated that code with the rest of the application, we faced unexpected results. To overcome such situations, continuation integration is very much needed. It becomes more important with Agile frameworks, where the nature of delivery is incremental, iterative, and in short cycles (as in Scrum, XP, or in fact in any other Agile framework). Continuous integration is possible only through an automated process that builds, tests, analyzes, and deploys the application. This process runs with each source-code change and provides immediate feedback to the development team. Minimum human intervention in these processes results in saving time. Continuous integration also reduces the risk of delivery slippage as the development team performs testing and integration on a continuous basis. This helps us identify defects in time and take appropriate and necessary action. The integration may be daily, weekly, nightly, release based, or for testers as per requirement -- and it must be, of course, done in a continuous manner.

How will the process be changed?

Manual process: 

Good flow, with no exception of errors faced during any of the following actions: 

Check out the source files from your source code repository.

Make necessary changes to the code.

Build. Run unit tests.

Check the updated code into the source code repository.

Automated process:

An automated system keeps track of the source control system and, as soon as it finds any change, it takes the latest version of the code.

The system automatically builds the code.

The system automatically runs unit tests.

The system automatically sends build and test results to a feedback system so that team members can know the current status of the build.

Necessary tools

Here I have mentioned a few open-source tools for Java and .net. There are many other such tools that may be adopted by teams as per their preferences. 

Source control: Such as Subversion or Git; these both can be used for Java as well as for .net

Server for continuous integration: CruiseControl.NET (for .net), Jenkins (for Java)

Build Manager: MSBuild and NAnt (for.net), Ant (for Java)

Unit test frameworks: MSTest and NUnit (for.net), JUnit (for Java)

Code-analysis tools: FxCop, StyleCop (for.net), CheckStyle (for Java)

Testing tools: Selenium (for both .net and Java) 

If you have more suggestions, please share.