Tool chain for projects, and how well they perform over time in projects

Question

In my previous job the tool chain was

Task control: FogBugz Development
Env: Visual Studio 2008
Source Control: SubVersion Integrated build: CruiseControl.NET
Unit Tests: Nant
Coverage: NCover
Output packaging: Zip Files

and some parts worked a lot better than others. I'm in the process of setting up a new tool chain for my current company and I am interested in other peoples environments, and which bits have worked, and which haven't worked.

Please can you include in your answers if you are a developer, tester or had task management responsibilities.

When I have a few answers in here, I'll add my experiences as well. I am not expecting to accept an answer here, as I doubt there is a "perfect" answer

Answer 1

The company I work for uses these tools:

Task control: VersonOne and Bugzilla
Environment: GCC/G++ and Eclipse/VIM
Source control: Git
Testing: Testlink, bci and a homebrewn automated test system
Unit tests: Homebrewn unit-testing library
Building with: waf and/or automake/autoconf

We use the homebrewn unit-testing library because part of the product is open-source and it needs to have as few external dependencies as possible.

Bugzilla worked out just fine. But it's only a bug-tracker, not a complete task control system.

The developement environment is mainly an individual decision for every developer, but they must be able to work efficiently with these tools.

We use waf for non-open source applications (internal mostly). It's easy to handle but not very good for applications that have to build on different platforms.

Testlink is for manual testing. We have only started using it a few months ago so it's too soon to tell if it's any good, but the testers seem to like it. The homegrown part is for integrating it with other company-wide systems and starting the automated tests and performance tests.

And Git worked out pretty well. The other devs like it since it's so easy to set up a git repository. We have a central server and every developer has a complete repository. We integrate patches to the mainline easily with our also homebrewn tool.

Answer 2

Task control: Pencil and paper (I'm the only dedicated developer)
Environment: XCode and Emacs
Source Control: Git
Testing: a bunch of sample applications I've written
Deployment: log into production, pull from Git, run make

Answer 3

There could be a perfect answer for the question if you can provide some details about the hierarchy of read/write rights to the code base, kind of project, etc.

If you look at the git repo of Linux kernel for example, you see the hierarchy of read/write rights which is pretty much flat, only differentiated by trust. But if you look at those of GCC or GDB, they are very different and have a pyramid like hierarchy.

As for me, I am a programmer. I use Emacs, CVS, Make, gcc, gcov/gprof, gdb/objdump/strace, shell scripts/python for testing. But some in my team use Vim. We have one central code base to which some of us write. So we use CVS.

Answer 4

Well, for a start, you want to get off Visual Studio 2008 and onto 2010, no doubt about it.

SubVersion may be doing the job for you - but it's definitely worth reading the first chapter of Joel Spolsky's Mercurial tutorial to see if you think it might be worth switching to a distributed version control system - it will certainly add functionality, which may or may not be compelling in your development situation.

And lastly, I did set up CruiseControl.NET once, and I seem to recall it being a pain in the ass. If you already have it working perfectly, you might as well stick with it. But if not, JetBrains' TeamCity has always been very well regarded by the people I know who have used it (I haven't, myself).

Answer 5

This is my experiences on the toolchain in the question, over 3 years on the project.

We found fogbugz very effective in defining tasks, task assignment and in predicting project progress. All round, this was a strong part of the tool chain.

Visual Studio 2008: Okay. Some problems with the large number of projects in the solution.

Source Control: SubVersion was okay in the intial stages of the product. However as progressed, we ended up with 5 products all from the same source code, each with different release points. The majority of the development team copy and pasted code between branches rather than merging across - and the result became bits of code being lost in branches rather than being in the trunk and merged into the branches properly. This was a weak area of the tool chain.

CruiseControl.NET: It was okay, but adding new branches means editing config files by hand. Using Nant with it to script the build process was easy to setup, but over time as newer .NET features were added, its limitations started showing. e.g. compiling XAML pages. I would probably find a replacement next time.

Unit Tests: NUnit generally did the job. most of the developers did not really push it hard, in terms of tear ups and tear downs etc but this part did its job catching coding errors.

NCover: We found running NCover semi useful. It was more a review tool when we found a bit of work that was found lacking in QA. It was often found that code coverage of unit tests was <10% in poor code.

Zip Files worked in our case because we were shipping an OEM product, and these files were then placed into ImageX WIM image files.

Answer 6

I wrote this in "Practical Development Environments" a few years ago.

Table 10-1. Typical Tool Life span (years) SCM tool 5-10 Build tool 8-15 Test environment 3-6 Bug tracking system 3-5 Documentation environment 5-10

I think I was off on the lifespan of SCM tools but others still seem about right.

Answer 7

What the hey:

Task control: Email + Redmine
Env: Visual Studio 2010 mainly, some 2008 and 2005 hanging out in dark corners.
Source Control: SubVersion, in the process of working out details to shift to mercurial
Integrated build: TeamCity
Unit Tests: NUnit generally, when we've got em Coverage: starting in on DotCover where possible
Output packaging: Subversion (yes, you read that right)

Note this is more of an internally facing situation, we don't ship software, we deploy software. So we've got a dedicated production svn repository to speak to that.

In my experience, the main piece that matters in a "we can't recover from mistakes there" way is source control. And then the main point is using it religiously rather than the underlying technology. Everything else is really a side effect.