Assuming you are already using source-code control the next step is automating the build process.

One of my current companys main products is a WIN32 application written in Borland Delphi. It consists of several EXE files and a bunch of DLL's. When I started here and I got asked to do a build there were several issues :

• The builds have always been done on my PC so prudence dictates that this one should also be done on mine ( e.g. in case another developer has different patch level on one or more of their software components ). But maybe I am halfway through making some changes to some source-code on my local PC. It will be a pain to copy that code somewhere and make sure I build with the required source then copy my changes back again.
• I would much rather somebody else could do the build but without risking a bad build due to different compiler options or patching e.t.c. et.c.
• To do the build there are lots of small projects to manually build, its time consuming and error prone. I also have to manually set version information on each project.
  
• After the build theres more work to do. Create a new SQL script folder in source-control ready for the next version. Add a file NotReleasedYet.txt and another version information changing script to this new folder. My manager will want a list of changes made in this newest build, that means hunting down the changes in emails and copying them into a other email.

Nowadays this is how we do a build ( any skynet worker can do this, you dont need any development tools on your PC ) :

• In "Internet Explorer" open a web-page
• Type in the version number we want to build
• Select our email address from a drop-down list
• Optionally type in our ICQ ( instant messaging ) number
  
• Press the relevant button depending on which product we want built
• Wait for an email confirming the build has started
• Optionally monitor instant messages describing progress
• Wait for the email saying the build was successful ( unless it failed which you will also be told ). A build-log is attached in case of failure. Otherwise the email tells you where to find the new version, a link to a document describing the changes in this version, a link to a directory containing any SQL scripts to run.
• A RSS feed of software changes is also updated.
• The new source-control SQL script folder is automatically created, the new SQL scripts are created and added to source-control. The existing source-code is automatically labelled in source-control.
  

This has saved an unbelievable amount of time. As a matter of routine after I check in any source code changes I do a test build to check I didnt break the build. It takes me no extra time to do this, I just wait for the success or failure email.

This was done using the software "FinalBuilder", some custom C# code ( including a website and windows-service ) and a old ( slow ) spare server machine.

You may be thinking you havent got the time to waste setting all this up.
Neither did we, I didnt stop developing to write all this in one go.

First write a basic FinalBuilder project which automates some of the steps leaving the rest as manual. This will save some time each time you make a build. Every build you now saves a little bit of time, use that time to keep increasing the automation until you reach diminishing returns, which I think we now have.

A future post might describe this process in more detail.

Having an automated build puts you in a good position should you want to add more automation :

• If you are using unit-testing the build process can also run some or all of the tests and email people if the tests failed. This could potentially be done anytime code is checked in.
  
• Static code analysis could also be automatically run. e.g. if its dotnet code maybe FXCOP could run and email back warnings.
• If you have an installer then the build process could be expanded to automatically create a new installation e..g with InstallShield