What Development and Build Lifecycle Tools Do You Use?

Question

I'm working on transitioning my current project of about 20 developers to a modern development and build environment. We currently use an RCS based source control system and an associated issue tracking system, both with Motif UIs. There is no formal production build process, its just whatever works.

I'm interested in:

• Development Tools
• Version Control
• Issue Tracking
• Dependency Management
• Configuration Management
• Automated Building
• Automated Testing
• Continuous Integration
• Artifact Management
• Release Management
• Deployment Management
• Requirements Tracing
• What else?

I'm interested in not just which tools you use, but how well the integrate with each other, how easy they are to setup and use, and how both developers and management likes them. Our project is a combination of Java, C++, and VHDL, but I'd still like to hear from people with other languages. I'm currently going down the path of eclipse, subversion, trac, maven, hudson, and nexus.

Also, is there a better term than "Build Lifecycle" that encompasses not just building, but the flow of code from when the developer creates it to when its built, tested, and in a production system? "Build Lifecycle" seems limited, but "Project Lifecycle" is already taken.

Answer 1

I hate Maven less than I hate Ant, and for Java, you need to choose one of those evils. If you're just starting out, choose Maven, especially since you've already recognized that your "build lifecycle" encompasses 12 different and complex disciplines! You're going to have to choose conventions for all of them. Save yourself the trouble and go with the conventions Maven has already established.

For continuous integration and general build automation, I like Hudson.

Answer 2

During the last two years we gradually switched from a "every-project-has-its-own-toolset" strategy to a Trac+SVN+SCons solution and are quite happy with that.

Switching to SCons was a bit of work but really paid off. We have a heterogeneous environment, mostly C/C++ for different embedded platforms, kernel modules, some desktop applications and various Python modules as glue code. SCons really shines when you want to add support for your own compilers and niche-tools and need to adapt the build system to your requirements. Formerly, we had to use a different GUI for almost every embedded platform - now that SCons directly invokes the compilers the work-cycle has slightly improved.

Our developers either used Emacs or Vim and no one wanted to switch to anything else, so we (fortunately) sticked with that. I'm not very familiar with deployment so I can't talk about that.

Answer 3

We're an MS shop using VS2008. We use Subversion with Tortoise for SCC and versioning, and our repository is hosted online so our distibuted team can use it. For build we're using Hudson and CI, much better than Nant or MSBuild. Issue tracking is Bugzilla. Automated testing is NUnit

Tools to avoid include Team Foundation Server and Sharepoint, too clunky for real world usage.

BTW Does anyone know a good Scrum tool, which can produce burn down charts, ideally linking into Basecamp?

Answer 4

If you work with .NET, it's hard to beat Team Foundation Server for its integration with Visual Studio. It contains the development tools, version control, issue tracking, configuration management, automated testing, unit testing, automated building, artifact management and everything else you've described.

Of course, TFS is expensive, oftentimes non-intuitive and is missing some features compared to other tools I've used. If you have a MSDN license you can use TFS for Workgroups (up to 5 users IIRC) for free, though.

Answer 5

• Development Tools JetBrains IntelliJ IDEA
• Version Control Subversion
• Issue Tracking Atlassian Jira
• Dependency Management Maven
• Configuration Management TeamCity
• Automated Building TeamCity
• Automated Testing JUnit(?)
• Continuous Integration TeamCity
• Artifact Management Maven
• Release Management Homo Sapien
• Deployment Management Maven/Homo Sapien
• Requirements Tracing Wishful thinking
• One-Off Automation Bash
• Developer-to-Developer Documentation MediaWiki

Answer 6

We also use a number of tools, but we're moving more and more to Zed Builds & Bugs. Our primary dev environment is Eclipse + Java, but we also do Visual Studio (all of 'em), and at least 5 different unix platform builds.

Here's the full list:

• Development Tools - Eclipse
• Version Control - Subversion
• Issue Tracking - Zed Builds & Bugs
• Dependency Management - Ant
• Configuration Management - Zed Builds & Bugs
• Automated Building - Zed Builds & Bugs
• Automated Testing - JUnit
• Continuous Integration - Zed Builds & Bugs
• Artifact Management - Zed Builds & Bugs
• Release Management - Zed Builds & Bugs
• Deployment Management - Zed Builds & Bugs
• Requirements Tracing - Zed Builds & Bugs
• One-Off Automation - Zed Builds & Bugs
• Developer-to-Developer - Zed Builds & Bugs

Answer 7

I use svn and tac on some oof my projects and svn and fogbugz on others. They integrate very well.

I am still using command line scripts for builds as they do everything I need - including grepping for errors and emailing results, but the days of that setup are numbered. I am looking into cross-platform build tools.

I use Inno for win32 releases. No shipping products yet for other platform - not sure how we'll deploy those.

We don't address a lot of the other items you mention other than on some ancillary documentation and in the code and in issue tracking.

Answer 8

Team Foundation Server and Visual Studio.

I remember when my ide was Sun's visual C debugger, and source control was copying all source files to a new named directory and putting it on a server that was supposed to be backed up.

Only it wasn't