Hacknot's If They Come, How Will They Build It? is a harrowing series of 29 emails sent over a two week period.
Back to the tools:
I would definitely suggest Maven2 as a build system in Java. The difference between Ant and Maven is that Ant does not protect developers against themselves. It is script after all and is fairly easy to mess up.
On the other hand Maven is not that powerfull in terms what you can do during the build, but you get a huge benefit in standardization.
Maybe you have noticed that many open source projects leave Ant and start building with Maven;-)
“How long does it take for you to get a new team member working productively on your project? If the answer is more than one day, you have a problem. Specifically, you don’t have a proper build process in place.”
I totally agree that F5 is not a build process. Actually it’s never meant to be one. But what a build process has to do with a new guy in the team? The new guy may be a trainee, a fresh college graduate. Lots of software houses don’t allow newcomers to commit code in the source repository for some time.
Jeff - please spent some more time reading your draft posts. Those two lines spoiled the entire post… Don’t lower your standards.
I think the take-away here is that:
(a) all and any member of the team should be able to retrieve a current, working copy of the code in a simple manner.
(b) all code should be checked against a “clean” system to ensure it compiles without undocumented/unscripted tweaks.
© checking in code is the equivalent of saying “this portion is done” - if it doesn’t compile, you’re not done, and don’t check it in.
this is just one point of view, all it depends on size of your project, number of contributors and dependencies. adding proper build process into your project will require at least one more new dependency (http://www.codinghorror.com/blog/archives/000497.html) and add some more new code (http://www.codinghorror.com/blog/archives/000878.html) which have to be maintained and that’s not a good thing. so really, we’re talking here more about trade-off than requirement.
Are there still people that have code in their source repository that doesn’t compile? That’s probably the most strictly enforced rule around here.
I’ve been meaning to get build scripts setup since I started the last project but I haven’t gotten around to it because as you say, F5 is just easier. How do you build and run / debug an application? Or do you hook up F5 to just run your build script?
@Jon - I have to assume that either you only ever work on one-man projects, or you hate your colleagues. 
Jon,
Not everyone who builds software continually checks in perfectly working code. If you are working on something that you aren’t going to get done in a working day and will break the build if checked in, branch that development and merge it into the main trunk once you are done.
Peter
Generally in the open source world things are better in this regard, for a couple of reasons. The obvious one is that most people would like contributions from others, and the non obvious one is that there is not a standard IDE that one can hit F5 in :). Unfortunately in my experience some projects are still very difficult to build which is a huge barrier to entry for most.
Hmm, I should add a “ease of build” metric to my “open source openness score”:
http://www.pixelbeat.org/docs/oss_project_quality.html
cheers.
Keeping code that doesn’t compile in source control shouldn’t really be a problem if your source control system supports something similar to Team Foundation Server’s “shelving”. It lets you push checked out files up into a temporary storage area that is still in source control, but not in the main branch. Then your existing checkouts get undone. When you are ready, you can come back and pull down the shelved files and your checkouts get redone.
Admittedly I don’t have much experience with source control outside of Source Safe, TFS, and Vault. Other products may support something similar.
Two years ago we tried to make a dedicated build server, it was a total failure for our middle-sized Windows C++ project.
To make the build outside the IDE, you have to create your makefiles and a few scripts for other jobs, like invoking 7zip to create the binary data file. We wasn’t lucky with our project leader, he was a python guru, and he insisted that our build script would be made in python. So it was. The build system emerged, and everything was working.
A few days later a pile of new source files were added to the project. The scripts had to be modified to include those files in the build. Here came the first problem: it turned out that only 2 of 8 programmers have knowledge in makefile and python syntax. Modifying the project content would need one of these two guys.
We also struggled to synchronize the scpits with the IDE settings. There were times when the project built finely through the IDE but took hours to find why the script won’t work. Lots of hours.
Two months later the “build server” idea was dropped. It didn’t help us to find any problem, but took much work to maintain. I don’t doubt that in some places the build server is a good idea, but for us it was a waste of human resources.
“The F5 Key Is Not a Build Process”
Of course not. It’s F7, dummy. 
Seriously, with IDEs (eq. VisStud) there are multiple issues. You need to get the script to use the same options to the compiler as VC does, and when the build script yields results different from the IDE the blame is always with the build script writer. 
We went as far as to generate the .dsp files from a description, so not everyone has to patch them themselves.
I recently implemented a simple “v1.0” build process using batchfiles that call the IDE. It’s not perfect, but it’s buying the time to climb the learning curve towards NAnt and CruiseControl.NET integration.
As always, get the the v1.0 with the minimum requirements to be useful, and then start improving. I guess too many software teams never get a “proper” build process off the ground because they think they should be using NAnt and don’t have the time to learn it, so never get off the ground.
Well, just to remind you, Visual Studio project file is MSBuild script file and so each project can be built using “MSBuild MySuperProject.csproj” command. So most people have build script already, but they never use it outside Visual Studio, which is where you are completely to the point.
@Jon
If you really don’t want to branch and merge, which would be the best way to do it, you could always check in more frequently, and immediately revert the changes. Everything is source controlled and daily build doesn’t break. /hack
Hear hear!
One thing that’s often overlooked are database builds. Even when a project has a centralised build process, it’s often hampered by all the develpers working against a central development database, not under source control, just backed when someone wants to deploy to test.
I wrote about it here:
http://mikehadlow.blogspot.com/2006/09/how-to-do-database-source-control-and.html
And Secret Geek has a good discussion here:
http://secretgeek.net/dbcontrol.asp
Within our company, most projects are a one-person deal. So, the F5 key very much becomes the build process.
As others have mentioned, there are times when I am making a change which may not be completed by the end of the day. I still check them in. Sure, I could branch and merge, but since I’m the only one working on it, that’s overhead that gains me (or the company) nothing.
Easier build processes would help many open source projects, I’m sure.
Ever tried to compile Thunderbird or Firefox on Windows? I wanted to contribute to TB, add some desperately needed features like default templates, but couldn’t build the damn thing. I set up a fresh VM and followed the instructions, only to get build errors so gave up after hours of trying. Now TB doesn’t have default templates, a really basic feature.
Someone suggested that a Linux based VM should be made for TB, which would could be downloaded and run on any platform. That way, the build environment would be set-up for developers already and they could just start coding. I think the biggest issue was licensing though, since on Windows TB only builds properly in VisualC. VC is free but probably not free enough to include in a VM.
I go the other way: the IDE is my automated build. That means that when you debug, you’re using the exact same build instructions that you’ll be using to produce your final released code. Going the other way, trying to get the debugger to debug something you built with a different build process, is always an exercise in frustration because the IDE wasn’t really designed to do this. The makefile project is a complete cop-out.
To do a command-line build, you can still use Visual Studio - devenv /build (or if still using VS6/eVC, msdev /make). The problem with this approach for a build server is of course that you need a copy of the development environment on the server. For .NET 2.0 projects, MSBuild can handle .csproj and .vbproj files, but can’t do C++ projects - for that you need VCBuild which as far as I know only comes with Visual Studio (not the .NET Framework SDK).
I should note that I mainly work with mobile devices running Windows Mobile or OEM Windows CE platforms. Traditionally, with eVC 3.0 and 4.0, it was such an utter pain in the backside to get a command-line environment set up to build, assuming you could then get a makefile. Why? Because the platform-specific defines were configured in the registry!