我正在努力将当前由大约 20 名开发人员组成的项目过渡到现代开发和构建环境。 我们目前使用基于 RCS 的源代码控制系统和相关的问题跟踪系统，两者都带有 Motif UI。 没有正式的生产构建过程，只要有效即可。
我感兴趣的是：
- 开发工具
- 版本控制
- 问题跟踪
- 依赖管理
- 配置管理
- 自动构建
- 自动测试
- 持续集成
- 工件管理
- 发布管理
- 部署管理
- 需求跟踪
- 还有什么？
我不仅感兴趣的是您使用哪些工具，还感兴趣的是它们之间的集成程度、它们的设置和使用是否容易，以及开发人员和管理层对它们的喜爱程度。 我们的项目是 Java、C++ 和 VHDL 的组合，但我仍然希望听到使用其他语言的人的意见。 我目前正在沿着 eclipse、subversion、trac、maven、hudson 和 nexus 的道路前进。
另外，是否有比“构建生命周期”更好的术语，它不仅包含构建，还包含从开发人员创建代码到构建、测试并在生产系统中的代码流？ “构建生命周期”似乎有限，但“项目生命周期”已经被占用了。
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.
发布评论
评论（8）
我对 Maven 的厌恶程度还不如对 Ant 的厌恶程度，而对于 Java，你需要在这些罪恶中选择其一。 如果您刚刚开始，请选择 Maven，尤其是因为您已经认识到您的“构建生命周期”包含 12 个不同且复杂的学科！ 您必须为所有这些选择约定。 省去麻烦并遵循 Maven 已经建立的约定。
对于持续集成和一般构建自动化，我喜欢 Hudson。
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.
在过去的两年里，我们逐渐从“每个项目都有自己的工具集”策略转向 Trac+SVN+SCons 解决方案，对此我们感到非常满意。
切换到 SCons 需要做一些工作，但确实得到了回报。 我们有一个异构环境，主要是针对不同嵌入式平台的 C/C++、内核模块、一些桌面应用程序和各种 Python 模块作为粘合代码。 当您想要添加对自己的编译器和利基工具的支持并且需要根据您的要求调整构建系统时，SCons 确实会发挥作用。 以前，我们必须为几乎每个嵌入式平台使用不同的 GUI - 现在 SCons 直接调用编译器，工作周期略有改善。
我们的开发人员要么使用 Emacs，要么使用 Vim，没有人想切换到其他任何东西，所以我们（幸运的是）坚持使用这一点。 我对部署不是很熟悉，所以我不能谈论这个。
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.
如果您使用 .NET，Team Foundation Server 与 Visual Studio 的集成很难被超越。 它包含开发工具、版本控制、问题跟踪、配置管理、自动化测试、单元测试、自动化构建、工件管理以及您所描述的所有其他内容。
当然，TFS 价格昂贵，通常不直观，并且与我使用过的其他工具相比缺少一些功能。 不过，如果您拥有 MSDN 许可证，则可以免费使用 TFS for Workgroups（最多 5 个用户 IIRC）。
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.
我们是一家使用 VS2008 的 MS 商店。 我们使用 Subversion 和 Tortoise 进行 SCC 和版本控制，并且我们的存储库在线托管，以便我们的分布式团队可以使用它。 对于构建，我们使用 Hudson 和 CI，比 Nant 或 MSBuild 好得多。 问题跟踪是 Bugzilla。 自动化测试是 NUnit
工具，要避免包括 Team Foundation Server 和 Sharepoint，它们对于现实世界的使用来说太笨重。
顺便说一句，有人知道一个好的 Scrum 工具，它可以生成燃尽图，最好链接到 Basecamp 吗？
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?
我们还使用许多工具，但我们越来越多地转向 Zed Builds & 虫子。 我们的主要开发环境是 Eclipse + Java，但我们也使用 Visual Studio（全部），以及至少 5 个不同的 Unix 平台构建。
以下是完整列表：
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:
我在我的一些项目上使用 svn 和 tac，在其他项目上使用 svn 和fogbugz。 他们整合得很好。
我仍在使用命令行脚本进行构建，因为它们可以完成我需要的一切 - 包括 grep 错误和通过电子邮件发送结果，但该设置的日子已经屈指可数了。 我正在研究跨平台构建工具。
我使用 Inno 作为 win32 版本。 尚未为其他平台提供产品 - 不确定我们将如何部署这些产品。
除了一些辅助文档、代码和问题跟踪之外，我们不会解决您提到的许多其他项目。
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.
Team Foundation Server 和 Visual Studio。
我记得当我的IDE是Sun的Visual C调试器时，源代码控制将所有源文件复制到一个新的命名目录并将其放在应该备份的服务器上。
只是它不是
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