Coding   Practice: What should I do if my project doesn’t automatically build and deploy to assembly?
As early in your project as possible, you should implement automatic build and deployment to your shakeout and assembly environments with a target of about 30 – 40 deployments per sprint.  This process is key to the quick creation of features and early testing of those features within a sprint.

Quote:
“There are seven practices that we’ve found work well for individuals and teams running CI on a project:
– Commit code frequently
– Don’t commit broken code
– Fix broken builds immediately
– Write automated developer tests
– All tests and inspections must pass
– Run private builds
– Avoid getting broken code”
– Paul Duvall

Application:
If you break a build, then you need to fix it within 10 minutes. Pay attention to the status of the automatic build and back out your changes if you have to in order to get the build working again. Everyone on the scrum team should be included on the automated communications regarding build status for your team’s builds.

As you strive for excellence in your automated build and deployment process:
1) Include automated unit tests as part of your definition of a broken build. All unit tests should pass.
2) Include automated acceptance tests as part of your definition of a broken build. All acceptance tests should pass.
3) Include build warnings as part of your definition of a broken build. A build should complete with no errors or warnings.

References:
Continuous Integration: Improving Software Quality and Reducing Risk