aldon和.net开发

我在一家与你类似的公司工作——在我们的案例中,有大量的iSeries COBOL代码和越来越多的.NET系统的遗留代码库,.NET开发人员已经成功地游说使用Subversion进行源代码控制。在我对产品进行评估的短暂时间里,aldon在分支和标记等领域似乎一点也不灵活,并且有一个非常繁琐和神秘的界面。由于产品生命周期(mis)在我们的商店中是单独管理的,因此将aldon的.net使用仅限于源代码管理,这是一个简单的决定。在.NET世界中,Aldon在功能和可用性方面远远落后于标准的开源工具,并且没有希望与TFS竞争。在我们的例子中,在aldon之外管理.net代码无疑提高了开发人员的工作效率并减少了挫折感。

一个例子…来自一个Subversion商店,我试图找出如何在Aldon创建一个实验分支。如果有可能的话,文档很好地掩盖了这个特性,而我们的aldon管理员从来没有遇到过这个概念。我们店里的所有东西都被锁得严严实实,需要管理员权限来创建项目、版本等。从生命周期管理的角度来看,这可能是值得的,但从开发人员努力完成工作的角度来看,这是一个杀手。我不认为生命周期管理和源代码控制属于同一个软件,而aldon也没有做任何事情来阻止我的这种观点。

我想你会发现这里没有人用它。.net用户分为两类-那些“便宜的”(即试图节省成本),然后基本上你看起来像开源。而那些付出很多的人,其中大部分都是使用团队系统,因为它是从下往上集成到visual studio中的。对于.NET开发人员来说,AS/400是一个非常罕见的混合体,所以,到最后——你可能只是运气不好。

我个人甚至不确定是否会为此而烦恼。像团队系统这样的东西比追踪来源等要多得多——有很多好的测试特性,内置的持续集成等,所有这些都不需要通过兜帽来——很好地——得到一个低劣的产品。

几年前,当我们在一群rpg开发人员中间启动第一个.net项目时,在我的工作场所遇到了同样的问题。当时,我们选择使用一个单独的源代码管理系统(subversion)来处理.net中编写的任何东西(或者其他任何有人想使用它的东西)。我们将所有的项目(.net和as/400)转移到gemini中,以便进行时间和缺陷跟踪。基本上,我们选择了一个单独的产品来管理我们的.net和as/400项目,这是一个高层次的,但是用于版本控制、自动构建、自动测试等的不同工具。

几年后,我可以高兴地说,这对我们来说已经很好了。我真的想不出这会引起什么问题,但可以证明,它避免了一些潜在的头痛和头部撞击。我认为通过选择一个广泛使用的版本控制系统,您将更容易找到(好的).net开发人员)。我不能代表任何人说话,但对我来说,我使用的是一个版本控制系统 从没听说过 在面试的时候会有点危险。