CODEWITHSUNDEEP
build-processbuild-automation
John Ellinwood
John Ellinwood

Reputation: 14531

What Development and Build Lifecycle Tools Do You Use?

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:

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.

Upvotes: 10

Views: 1094

Answers (8)

Larry Watanabe
Larry Watanabe

Reputation: 10184

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

Upvotes: 0

Tim
Tim

Reputation: 20360

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.

Upvotes: 0

Steven M. Cherry
Steven M. Cherry

Reputation: 1375

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:

Upvotes: 0

Trampas Kirk
Trampas Kirk

Reputation: 1446

  • 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

Upvotes: 2

Paul Lefebvre
Paul Lefebvre

Reputation: 6406

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.

Upvotes: 3

MrTelly
MrTelly

Reputation: 14865

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?

Upvotes: 1

Pankrat
Pankrat

Reputation: 5316

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.

Upvotes: 3

jcrossley3
jcrossley3

Reputation: 11764

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.

Upvotes: 4

Related Questions