software-lifecycle - Aldon 和 .Net 开发

Question

我正在寻找具有使用 Aldon 作为生命周期管理平台经验的 .Net 开发人员的反馈。我们正在认真考虑使用 Aldon 进行生命周期管理，包括源代码控制、自动构建等。我知道还有很多其他选择，但我们主要是一家 AS/400 商店(AS/400 程序员数量超过 .Net 开发人员6 比 1)，并且我们的 iSeries 团队已经使用了 Aldon。我们正在寻找的好处是拥有一个生命周期管理套件。

基本上，我正在寻找使用过 Aldon 和另一组工具(可能是 TFS，或 SVN、Cruise Control 等的组合)的人的意见。如果您与两者都合作过，您是否有关于这是一个好主意还是一个坏主意的建议？这显然是一个很大的选择，因此任何反馈都会有所帮助。

编辑 - 添加

没有答案或评论......还有我的第一个风滚草徽章。我不确定这是否只是一个糟糕的问题，是否没有人真正使用 Aldon 来管理他们的 .NET 工作，或者是否没有人使用 Aldon 使用其他产品并且可以提供比较。

所以，我提供悬赏来增加交易的吸引力，并扩大问题的范围......如果有任何人在使用 Aldon，你能提供关于你遇到的问题的任何信息吗？工具套件、挫折或陷阱、你喜欢的东西等？

添加 - 甚至更多
我们的主要目标是拥有一个产品来管理我们的 .NET 和 AS/400(主要是 RPG)开发。如果您对不同的工具套件有建议，或者已经尝试过并认为它不值得，我也会接受这个答案。

Answer 1

我在一家与您类似的商店工作——在我们的案例中，有大量 iSeries COBOL 代码的遗留代码库，以及越来越多的 .NET 系统——并且 .NET 开发人员已成功游说使用 Subversion源头控制。在我对产品的短暂评估中，Aldon 似乎在分支和标记等领域根本不是很灵活，并且有一个非常繁琐和神秘的界面。由于产品生命周期在我们的商店中被单独(错误)管理，将 Aldon 的 .NET 使用限制为仅源代码控制，这是一个简单的决定。在 .NET 世界中，Aldon 在功能和可用性方面远远落后于标准的开源工具，并且没有希望与 TFS 竞争。在我们的案例中，在 Aldon 之外管理 .NET 代码无疑提高了开发人员的生产力并减少了挫败感。

一个例子......来自Subversion商店，我试图找出如何在Aldon中创建一个实验性分支。如果可能的话，文档在掩盖该功能方面做得很好，而我们的 Aldon 管理员从未遇到过这个概念。我们店里的一切都被严密锁定，需要管理员权限来创建项目、版本等。从生命周期管理的角度来看，这可能是值得的，但从试图完成工作的开发人员的角度来看，这是一个杀手。我不认为生命周期管理和源代码控制属于同一个软件，并且 Aldon 没有采取任何措施来劝阻我的这种观点。