Tools to help a small shop score higher on the "Joel Test"

Question

Questions #1 through #4 on the Joel Test in my opinion are all about the development tools being used and the support system in place for developers:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?

I'm just curious what free/cheap (but good) tools exist for the small development shops that don't have large bank accounts to use to achieve a positive answer on these questions.

For source control I know Subversion is a great solution, and if you are a one man shop you could even use SourceGear's Vault.

I use NAnt for my larger projects, but have yet to set up a script to build my installers as well as running the obfusication tools all as a single step. Any other suggestions?

If you can answer yes to the building in a single step, I think creating daily builds would be easy, but what tools would you recommend for automating those daily builds?

For a one or two man team, it's already been discussed on SO that you can use FogBugz On Demand, but what other bug tracking solutions exist for small teams?

Chihuahua

Answer 1

1. source control: Subversion or Mercurial or Git
2. build automation: NAnt, MSBuild, Rake, Maven
3. continuous integration: CruiseControl.NET or Continuum or Jenkins
4. issue tracking: Trac, Bugzilla, Gemini (if it must be .NET and free-ish)

Don't forget automated testing with NUnit, Fit, and WatiN.

Usquebaugh

If you want it to be .NET and free, as opposed to free-ish, then BugTracker.NET rather than Gemini. Has great Subversion integration. – Microgram

Answer 2

1) Subversion

2) Ant / Maven

3) Continuum

4) Bugzilla / Trac

Neogene

Answer 3

My preferred stack:

1) Subversion. I'm intrigued about distributed source control but haven't had chance to try any in anger yet. For a centralized solution svn is rock solid.

2) Ant. Maven is a joy to use when it's working but as an old ant hacker I find maven to be hard to follow once things go wrong.

3) Hudson. Not been mentioned so far but definitely worth investigating. Incredibly usable and actively maintained tool. PreviousLy we paid for Anthill Pro which seemed flakey and was painful to fix each time it screwed up.

4) We pay for jira. Not cheap but much more usable than the open source options we looked at and very flexible too.

Berretta

Answer 4

My engineering stack:

1. Git (I love GitHub, but Git doesn't require a hosted solution)
2. Rake
3. CruiseControl.rb
4. FogBugz

No doubt these choices are influenced by my development stack, which most often includes Ruby, Rails, SQLite, Firefox, and OSX.

Himelman

Answer 5

You may want to look at an existing question of mine for finding an alternative to Team System. There are plenty of recommendations in there also.

Ioves

Answer 6

1. Git
2. Make
3. Cron
4. Trac

I'm a man of few syllables ;-)

Be sure to use some kind of version control where developers can easily create private branches willy-nilly, then take their private branch and squeeze it into a single commit on the main branch. That way, individual developers---as opposed to the organization---can get the benefits of version control without polluting anyone else's code (and slowing down their work) with broken commits.

This feature is what I like about git. I think it's only really present in distributed version control systems; using a DVCS doesn't mean you actually have to do distributed development, though.

Regarding one-step building, make is the default build tool and it works quite well for most tasks. I'd go with that unless you have a good reason not to.

You want daily builds, put the build command in your cron.daily. Set up a procmail hook to handle the mail from cron if need be.

For bug tracking, use $(apt-cache search bug tracking). Basically, as long as it says "bug tracker" on the box and you know other people are using it, it's probably going to work fine. Among the regulars are bugzilla, mantis and trac.

Padraic

Answer 7

I don't have any tools to suggest, but I do have a suggestion about the daily builds. I always answer yes to that question, even though we don't have daily builds. Instead, we do a build every time someone does a commit. We thereby catch any problems almost immediately. If any of our projects ever has enough LOC that building takes more than trivial time, doing this will also gracefully degrade in the direction of a daily build.

Jedthus

Do you rebuild all what (propably) depends on commited code? In some cases (change in one of base component) can cause rebuilding whole application. How do you deal with building time ~hour for one commit? Thanks. – Lamson

After a commit, we wait 60s to see if more commits arrive. This mostly avoids building a tree with only one of several related commits. We build everything that depends on the code committed. For our "toolkit" project, this can be 10 apps. The build for our largest app (~200k lines of Java) takes <1 min on our build box. Even so, commits can arrive during the build - in which case we build again as soon as the first build finishes. If our builds become longer, there'll be more chance of this happening. Eventually, we'd theoretically reach a situation where the the build box is always building. – Jedthus

Answer 8

A good issue tracker that was relatively inexpensive was axoSoft OnTime. I used it for years before getting MS TFS.

Nant and CruiseControl are staples of my environment.

Ninebark

Answer 9

I don't think you really need obfuscation on .Net any more (see another response)

I wouldn't consider Vault, SVN is really the market leader at the moment (and free). Git is looking pretty promising but currently is command line only with a steep learning curve.

MSBuild beats NAnt for .Net 2 or 3.5

CC.Net is excellent.

Alleviation

Answer 10

*4) Redmine

I recommend Bitnami for testing out different stacks. It's got Trac, Redmine, and Subversion, as well as several other unrelated ones.

Jerrold

Answer 11

Check out these articles on Continuous Integration using MSBuild, CruiseControl.NET, FxCop, NUnit, NCover and Subversion...

From the software development trenches

Milden

Answer 12

I'm currently using SVN but I've generally had a lot or problem with checkouts to a network drive on a dev server. There tend to be locking issues that require a lot of fishing around to fix. It may be that using the WebDav access method, would ease some of these problems, but I haven't experimented yet.

Any of Bugzilla, Trac or Fogbugz will help you with your bug tracking, and each offer an export feature, so you can always change your mind later on. Also, if you can get your team to fully buy in, time management software can also be handy for post-mortems, etc (if everyone is motivated to fully participate.

Eldrid

Answer 13

For build automation and continuous integration take a look at TeamCity from Jetbrains.

It has a lot of features and is really a breeze to set up and use.

If you use Visual Studio 2005/2008 it will build your solution directly without the need for extra scripts (if a build is all you want.)

It will also execute your unit tests and gather stats on build success, unit test execution times, etc, etc.

Best of all: The Pro edition is free for teams with up to 20 users and 3 build agents.

Outrage

Answer 14

1. source control: cvs
2. build gnu make
3. cron job that calls bash scripts
4. bugzilla

Batista