Aldon 和 .Net 开发
我正在寻找具有 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）开发。如果您对不同的工具套件有建议，或者已经尝试过并认为它不值得，我也会接受该答案。
I'm looking for feedback from .Net developers who have experience with Aldon as a lifecycle management platform. We're seriously considering using Aldon for lifecycle management including source control, automated builds, etc. I know there are a lot of other options out there, but ours is primary an AS/400 shop (with AS/400 programmers outnumbering .Net developers 6 to 1), and Aldon is used already by our iSeries team. The benefit we're looking for is having one lifecycle management suite.
Basically, I'm looking for opinions from people who have used Aldon and another set of tools (perhaps TFS, or a combination of SVN, Cruise Control, etc). If you've worked with both, do you have a recommendation on whether this is a good idea, or a bad idea? It's obviously a big choice, so any feedback would be helpful.
Edit - Added
No answers or comments... AND my first Tumbleweed badge. I'm not sure if this is just a bad question, if nobody actually USES Aldon to manage their .NET work, or if there's just nobody using Aldon that used other products and can offer a comparison.
So, I'm offering a bounty to sweeten the deal, and broadening the scope of the question... If there are any people out there USING Aldon at all, can you provide any information on issues you have had, is it a good suite of tools, frustrations, or gotchas, things you love, etc?
Added -even more
Our primary goal is to have one product to manage both our .NET and our AS/400 (primarily RPG) development. If you have a suggestion for a different suite of tools, or have tried it and decided it isn't worth it, I'll take that answer as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在一家与您类似的商店工作 - 在我们的例子中，有大量 iSeries COBOL 代码的遗留代码库，以及越来越多的 .NET 系统 - 并且 .NET 开发人员已成功游说使用 Subversion源头控制。在我评估该产品的短暂时间里，Aldon 似乎在分支和标记等领域一点也不灵活，并且有一个非常繁琐和神秘的界面。由于产品生命周期在我们的商店中是单独管理（错误）的，因此将 Aldon 的 .NET 使用仅限于源代码控制，这是一个简单的决定。在.NET世界中，Aldon在功能和可用性上远远落后于标准开源工具，根本没有希望与TFS竞争。就我们而言，在 Aldon 之外管理 .NET 代码无疑提高了开发人员的工作效率并减少了挫败感。
一个例子......来自 Subversion 商店，我试图找出如何在 Aldon 中创建一个实验分支。如果可能的话，文档很好地掩盖了该功能，而我们的 Aldon 管理员从未遇到过这个概念。我们商店中的所有内容都被严格锁定，需要管理员权限来创建项目、版本等。从生命周期管理的角度来看，这可能是值得的，但从试图完成工作的开发人员的角度来看，它是一个杀手。我不认为生命周期管理和源代码控制属于同一个软件，Aldon 也没有采取任何措施来阻止我的这种观点。
I'm working in a shop similar to yours--in our case, there is a substantial legacy code base of iSeries COBOL code, and a growing number of .NET systems--and the .NET developers have successfully lobbied to use Subversion for source control. In my admittedly brief time evaluating the product, it seemed like Aldon was not very flexible at all in areas like branching and tagging, and has a very cumbersome and arcane interface. Since product lifecycles are (mis)managed separately in our shop anyway, limiting the .NET use of Aldon to source control only, it was a simple decision. In the .NET world, Aldon lags far behind the standard open source tools in features and usability, and has no hope of competing with TFS. In our case, managing .NET code outside of Aldon has definitely increased developer productivity and decreased frustration.
One example...coming from a Subversion shop, I was trying to find out how to create an experimental branch in Aldon. If it is possible at all, the documentation did a great job of obscuring the feature, and our Aldon admin had never come across the concept. Everything in our shop is locked down tight, with admin rights needed to create projects, versions, etc. This might be worthwhile from a lifecycle management standpoint, but from the perspective of a developer trying to get work done, it is a killer. I don't think lifecycle management and source control belong in the same software, and Aldon has done nothing to dissuade me from that opinion.
我想你会发现这里没有人使用它。 .NET 人们分为两类 - 那些“便宜”的人（即试图节省成本），然后基本上你看起来或类似开源的东西。那些付出很多代价的人，其中大多数都选择了 Team System - 因为它是自下而上集成到 Visual Studio 中的。对于 .NET 开发人员来说，AS/400 是一种非常罕见的混合体，因此，最终 - 您可能只是运气不好。
我个人不确定我是否会为此烦恼。对于像团队系统这样的东西，除了跟踪源等之外，还有很多东西 - 许多良好的测试功能，内置持续集成等，以及所有这些，而无需通过引擎盖运行 - 好吧 - 获得劣质产品。
I think you will find nobody here uses it. .NET people fall into two categories - those that are "cheap" (i.e. trying to save costs) and then basically you look or something like open source. And those who pay a lot, and most of those go with Team System - because it is ingtegrated into Visual Studio from the bottom up. AS/400 is a pretty rare intermix for .NET developers, so, at the end - you possibly are just out of luck.
I Personally am not sure I would even bother with it. THere is a lot more to soemthing like Team System than tracking source etc. - lots of good testing features, build in continuous integration etc., and all that without running through hoods in order to - well - get then an inferior product.
几年前，当我们在一群 RPG 开发人员中启动我们的第一个 .NET 项目时，我们在工作场所遇到了同样的问题。当时，我们选择对用 .NET 编写的任何内容（或其他人想要使用它的任何其他内容）使用单独的源代码控制系统 (Subversion)。我们将所有项目（.NET 和 AS/400）转移到 Gemini 中以进行时间和缺陷跟踪。基本上，我们选择了单一产品来管理我们的 .NET 和 AS/400 项目，但使用了不同的工具来进行版本控制、自动化构建、自动化测试等。
多年后，我可以很高兴地说，这对于我们。我真的想不出这会造成什么问题，但可以证明它避免了一些潜在的头痛和冲突。我确实认为，通过选择广泛使用的版本控制系统，您将更容易找到（优秀的）.NET 开发人员。我不能代表任何人，但对我来说，使用我从未听说过的版本控制系统在面试中会有点危险。
We encountered the same problem at my workplace a few years back when we started up our first .NET project in the midst of a bunch of RPG developers. At the time, we chose to use a separate source control system (Subversion) for anything written in .NET (or for anything else that somebody wanted to use it for). We moved all of our projects (.NET and AS/400) into Gemini for time and defect tracking purposes. Basically, we chose a single product to manage our .NET and AS/400 projects at a high level but different tools for version control, automated builds, automated testing, etc.
Years later I can happily say that this has worked out quite well for us. I really can't think of any issues this has caused - but can attest to the fact that it has avoided some potential headaches and butting of heads. I do think that you will have an easier time finding (good) .NET developers by choosing a widely used version control system. I can't speak for anyone else, but for me the use of a version control system I have never even heard of would be a bit of a red flag in an interview situation.