Nightly builds for one-man projects

Question

I'm working on a C++ wrapper for libpcap and I'd like to get more into version control as I'm not experienced with this (the only reason I used it was to put code on GitHub :)).

Does it make sense to schedule nightly builds for a one-man project? What advantages are there in doing this?

Answer 1

You've got it a little bit from the wrong angle.

The important idea is that you need reproducible builds!

Given any deployment you need to be able to later reproduce the exact build process that generated that deployment, so you can debug it and fix it. Here it is important to use source control so you can retrieve those sources. To be absolutely certain that the sources are the same, you should use a robot to check out the sources from your source controle and then build your program. This has the added benefit of catching any dependencies not in source control.

If that process takes a long time to do (e.g. because you have a lot of tests in place) then it is nice to have the latest version available to everyone interested in the morning, i.e. you do a build at night. If you do not have that need, then nightlies are probably not necessary (but you'll want the robot though!).

Also learn your source control well including how it is usually used by others. This will give you tricks and ideas that will save you a lot of trouble in the long run.

Answer 2

Probably not.

The advantages of automated nightly builds only start to play when the team becomes so large that no individual team member can keep the entire project in their head anymore. When this happens, nightly builds ensure you always know whether you'd be able to ship if you had to, at any given time - but if you're going solo, you probably know anyway. It's still a good idea to have automated tests and a script that executes a full build (from clean checkout to shippable package) and run it every now and then: whenever you've completed a feature, refactored or rewritten some code, or did anything that could somehow break things.

Using source control, however, is an absolute must. Start using it, and you'll wonder how you ever managed to live without it.

Answer 3

I'd say automated builds are, if anything, more important on a one-man team. You can lie to yourself, but the CI server is much stricter master. She does not lie.

Answer 4

If anything, I would suggest setting up a continuous integration server like Hudson or Jenkins and have it build and execute your tests after a check-in, as opposed to nightly. This has the benefits of giving you feedback on the current health of the project on a regular basis as you work on it, without wasting time and resources building when no changes have been made.

Answer 5

Advantages

• The earlier you set up a Continuous Integration process the easier it is.
• Exposes errors earlier in the development process which is always cheaper.
• Provides a framework for other good habits like automated tests, automated packaging, automated tagging and versioning, etc.
• Leads you to better design (relocatable, correctly parameterized, config driven)

Disadvantages

• Time to setup the system (should be about 1-2 days for a simple setup)
• Cost of maintaining the server
• Cost of maintaining the service
• Cost of better design (relocatable, correctly parameterized, config driven,e tc)

You don't have the luxury of being sloppy in your code with CIs. If you hard-code paths, users, etc, the CI build is likely to break, especially if you have an automated test suite.