Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 12 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
100% agree, working on effectively a two man project at the moment and we have no need for nightly builds, it just is not necessary. Source control (and solid backups of source control), on the other hand, is a must. If you are doing a solo gig then something like Mercurial is a good option. – AlexC Sep 5 '11 at 22:31
I disagree - having a CI server to do automated builds is useful, even for a solo operation. I use TeamCity at home for my side projects and its invaluable. – Bevan Sep 5 '11 at 23:51
I use automated nightly builds as an automated deployment system. Works great. I understand you said "probably", but I think the way I'm doing it is really the best way. I don't have to SSH into the production servers to deploy, and I know that it will work 100% in a reproducible way every time. No human error, and I get a fresh deploy every night. – Jordan Sep 6 '11 at 4:14

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.

share|improve this answer
Exactly. And if you add in automated unit testing in the nightly build, then you have a nice setup. – Bjarke Freund-Hansen Sep 6 '11 at 7:39

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.

share|improve this answer
Just for info: Do use Jenkins, it supersedes Hudson. – Bjarke Freund-Hansen Sep 6 '11 at 7:40
@bjarkef Both are under active development still. In fact, Jenkins was last updated on 29 August 2011 and Hudson was last updated on 30 August 2011. The projects are just run and maintained by different people - Hudson is run by Oracle, while Jenkins is run by former Hudson developers. – Thomas Owens Sep 6 '11 at 9:44


  • 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)


  • 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.