Talk about build process at a high level before drilling into details.
Describe and showReference App functionality and architecture.Describe whatNant is.Walk through Nant Script through the compilation step.
Show Nunit GUIShow FxCop GUIWalk through Nunit and FxCop steps in build scriptDemonstrate what happens when a unit test fails.
Show Deployment script section of Build Script.Discuss process for deploying database scripts.Show resulting scripts
Show Cruise Control .netShow cctrayDemonstrate what happens when a build is triggered.
Using Continuous Integration To Ensure Project Health New
Using Continuous Integration to Ensure Project Health<br />Bart Lowe<br />Senior Consultant <br />
Continuous Integration<br />Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.<br />--Martin Fowler<br />Contrary to popular belief, continuous integration is an attitude, not a tool.<br />--James Shore<br />
Source Control<br />Developers should commit to the mainline frequently.<br />Ensures problems are found quickly when used in conjunction with self-testing builds.<br />Don’t commit changes that will break the build.<br />Developers should get the latest version and run a local test build before committing changes.<br />Store everything required to ship the product (including database scripts).<br />
Automatic Builds<br />Ensures that your build is documented & repeatable.<br />Tips<br />Build only from a full checkout of source control.<br />Maintain a history of past builds.<br />Make it easy for everyone to get latest executables.<br />Broken builds should be fixed ASAP.<br />Number your builds.<br />Keep your builds fast.<br />Treat build scripts as code. <br />Use a build scripting tool such as Nant.<br />
Self Testing Builds<br />Unit Testing<br />Test Driven Development <br />Failed Tests should cause the build to fail<br />Tool: Nunit<br />Code Coverage Testing<br />Tests the how much of your code is exercised by your unit tests.<br />Tool: NCover<br />Code Analysis<br />Validates conformance to design guidelines.<br />Tool: FxCop<br />
Automatic Deployment<br />Deployments can be just as error prone as builds.<br />Strive for one click deployments.<br />Create a deployment script for each environment (Dev, QA, Production)<br />Include a rollback mechanism in your deployment<br />Create deployment scripts with every build.<br />
Continuous Integration Server<br />A Continuous Integration server brings it all together.<br />Automatically triggers a build when a developer checks in code.<br />Provides a communication center for your build. <br />Records what changes where made since the last build along with who made the changes.<br />Alerts team members when a build breaks<br />Allows you to see detailed test results<br />Provides build history reporting<br />
Other Tools <br />Ndoc<br />Automatic class library documentation<br />http://ndoc.sourceforge.net/<br />Watir<br />Ruby based web application testing<br />http://wtr.rubyforge.org/<br />Fitnesse<br />Allows non-technical users to define acceptance tests<br />http://fitnesse.org/<br />Simian <br />Looks for duplication in large software code bases.<br />http://www.redhillconsulting.com.au/products/simian/<br />
For Presentation Slides & Files Email<br />firstname.lastname@example.org<br />