Daily Build vs. Zero Defect

Question

How do you go about doing a daily build and striving for a zero-defect environment? Does it mean I never get to go home until I've killed all the bugs in my new code? Or does it mean I just don't check my code back in until I've fully tested it, which leaves the code effectively branched for a much longer time?

I'm working with a handful of programmers for the first time (as opposed to working on my own, or with just one other coder), so I'm just wrestling with decisions like this for the first time. Should we adopt a software development process?

Answer 1

Simple: Never check in code with (known) bugs in it. This doesn't mean you check in once per day. Check in when you have a meaningful change implemented so the other developers can get access to it.

We always integrate locally, run our tests against the code, and when all passes, we check in. I check in about 20-30 times a day when working. The build server picks up changes and it runs builds against the system. Continous Integration (CI) is a good thing. :D

Continuous Integration - Automate Your Builds

Start out with building successfully and keep it that way as much as possible. It is essential in a team environment. Just remember that builds will break. It's expected that they break every once in awhile. It is a sign that you just inadvertently checked in something bad, and you stop what you are doing to make the build green again. A build server that never has broken builds is a warning sign!

I also agree with chadmyers' answer: Whatever you decide, it needs to be automatic and automated. The best thing about automating tools to do this kind of stuff for you is that you no longer have to think about it or remember to do it. Or like Chad said, you don't stop doing it. I could recommend make a recommendation for CI tools but have a look here: What tools do you use for Automated Builds / Automated Deployments? Why?

Once you have CI, you can get higher quality if you can inject some humor (and shame) by introducing a broken build token! http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

Use a Good Tool for Automated Builds

Most people in .NET land use NAnt or MSBuild scripts to have automated builds that they can later hook up to their CI server. If you are just starting out, my suggestion would be to use UppercuT, it is an insanely easy to use build framework that uses NAnt. Here is a second link with deeper explanations: UppercuT.

Branches vs Trunk for Active Development

You would not have to branch unless you leave trunk open only for releases (which means that everyone else is working in the same branch as you). But I would have CI on both the trunk and the active development branch.

Software Development Process

Also to answer the question on a software development process, the answer is a resounding yes. But don't rush into anything unless a drastic change is required. Pick a process you want to migrate towards and slowly start adopting processes. And evaluate, evaluate, evaluate. If the particular process is not working for your group, figure out if you are doing something wrong or if you just need to eliminate it. And then do. Whatever process you end up with needs to work for you or it won't work.