I mentioned before that one reason why having a code repository is great is because we can always go back to a stable state. Things become more complicated if other users are committing code as well. How do you know if the code in the repository is stable? And if it's not, how do you know whose change to roll back?
During my time in the LILT lab, I quickly became familiar with CruiseControl, which is a Continuous Integration (CI) tool. Whenever we committed code, the unit, functional, and acceptance tests would all run. And when everything was successful (cause I always checked my code... not) it would be green. And if someone broke something, it would be red. I actually was kind of afraid to commit code at times, since I was afraid of breaking the build and having the blame log be pointed at me (who was still very new to this whole programming thing). But I grew to accept it and became more comfortable using it. And I now understand how important it was to the overall health of the project.
In our software engineering class, we are creating a command line interface for WattDepot, which is part of a research project here at UH. This gives us the chance to apply a lot of the things we've learned over the past few weeks (automated QA, code repositories, and style guidelines) while working with fellow classmates. We were also introduced to Hudson, which is another CI tool that integrates with tools we already use in class (namely JUnit and Ant). It was pretty easy to set up so that it checked for a new commit every 5 minutes. At first, it failed the build since the code did not pass Checkstyle. Once that was fixed though, the weather cleared up and we haven't failed builds since. Make sure you run verify before committing!
So as Miss Kaylee Frye from Firefly/Serenity would say...