Do you use nightly builds for hobby projects?

Question

As probably 99% of the Stackers here I have quite a few Hobby projects running simultaneously, and I try to keep them under source control and get them to the point of the one-step build/test. But I've only rarely taken my hobby projects to the Nightly Build and Continuos Integration stages, because well I don't work on the projects every day. Now since my projects are already have a one-step build, it's not a far shot to Nightly Builds and Continuos Integration, but I have never really felt the need for either in a one man team.

The Cons of Night Builds and C.I. on Hobby projects as I see them are:

• large implementation overhead
• very little ROI (Return on Investment)

The Pros... well I can't think of any, so thats why I'm asking.

[Edit] Apparently, as I guessed, there seems to be a consensus that its not worth it for the one-man team. Now I don't feel like I'm slacking anymore thanks! ;)

[Edit] So there is some dissent, and a few Pros for NightBuilds... Back to wondering

Answer 1

No.

The purpose of a nightly build is to ensure that code committed by multiple developers does not 'clash' - prevent compilation or break unit tests.

If you don't have multiple developers, there's no point.

Edit: When I wrote this, the question only referred to nightly builds - not CI in general. I do think CI is a good idea for one man shops: the difference is that a one man shop can know when it's appropriate to kick off a build + integration test.

Answer 2

Nightly builds require a dedicated build machine. I do not use them. My approach is to never commit the code which does not build. It is enough for me.

Answer 3

I don't even use nightly builds for the projects that I Individually make for business.

Nightly builds are so that a team can make sure that no team member has submitted code that breaks the compilation. Good for teamwork, not necessary for individuals.

Answer 4

Yes, I do use these.

Advantages:

• It helps to make the dependencies explicit (i.e.: ensuring that I do not forget to include some 3rd party libary or tool that sits quietly somewhere on my dev machine).
• Makes sure that hobby project always compiles against the latest versions of some 3rd party libraries
• If I were to make a change for me or myself, I just need to commit, wait and download tested and nicely packaged deliverables
• You just spend 30mins once and then reap the rewards after that.

So on the overall it just reduces the development friction and makes you a more disciplined and efficient developer.

PS: I do not use just nightly builds. Full integration cycle runs on every commit, just to make life easier.

Answer 5

When it comes to best practices, I think a good rule of thumb is that they can often be scaled down, but they should never be skipped completely.

In this case an advantage I can see to a nightly build even in the individual developer case is if you checkout your tree on multiple machines (for example a desktop and a laptop, and deployment). An explicit build from svn will help keep you honest and spot stuff you forgot to check in or out. It's not the 'nightly' part that matters though - it's the 'from svn' part, and the 'done regularly' part. It's also a good point to run your time consuming tests.

I also don't think it's that difficult to arrange a nightly build for any reasonable dev setup anyway, it's just a matter of a cron job that checks your code out and builds it / tests it. The difference between that and what you do normally should not be much more than the cron job. If that seems a lot of overhead to do, it may be that points to other issues in your setup?

Answer 6

We do unit tests for the code.
We do continuous integration for the solutions.

Just like people do TDD when they develop alone (since it helps to produce better and more maintainable code and make the development cheaper in the long run), CI is recommended for sole developers also (for the same reasons).

Answer 7

I don't use them (I just have nightly source code snapshots), but because I had no time to setup a build server (an Atom-based server is very cheap). At any rate, I think nightly builds are valuable for users who experience specific problems: they can download patched builds they can install immediately without the need to check out the code from the repository and build it.

If you can afford the nightly builds (or even CI), I encourage you to set them up.

Answer 8

I use source control and unit tests on small hobby projects because they help me produce better code. Nightly builds wouldn't do that. The only reason I can think of to do this is if you want to learn how to set up nightly builds. (Not that there's anything wrong with that.)

Answer 9

large implementation overhead

If you've got a build script and version control already then running a CI build shouldn't be a large implementation overhead... providing you have a machine where you can just configure and then forget your CI tool.

That said, I haven't been running CI on my hobby projects but only because I didn't have a good way to configure a machine and let it run (no persistently running desktop machine to act as the "server"). But I've recently figured out how to use launchd to keep CruiseControl running on my laptop -- how to have it autorestart across reboots -- so I intend to start.

Wrt a "Nightly Build", if you're doing a CI build after each commit then I don't see the point.

Answer 10

I do use Hudson for my personal Java projects. I have it running on the same VPS that runs my website. This server has only 256mb of RAM, so it's a bit of a tight fit. I run it under Jetty, which is fairly slimline but if I get high traffic to my website, I turn it off to free up resources.

I don't think that CI is as beneficial in a one-man team because integration isn't really a problem when there's only one person making changes. It has been useful though. For example, if I forget to add some file that is vital to the build. Because it's Hudson, it also helps to track test coverage over time and builds up a change log from the commit messages. Because it's publicly available (go easy on it, it's a bit slow due resource constraints), it means other people can download snapshots of my projects without having to build them themselves.

I'd say that for personal projects CI is a nice-to-have, it's definitely not essential.