We have a large ASP.NET project consisting of several hundred reports. We are in the process of moving all the SQL Queries (running against an Oracle Database) into three web services. The web services are categorized by command, selections and report queries. We have to deploy a sub-set of our project using a SQL*Server backend to several locations that are disconnected from the Internet. Therefore, having all connections to the database and queries in the web services makes the application manageable and we can pull the sub-set of reports and not have to modify the code. The project is under source control using Serena ChangeMan software.
我们有一个包含数百个报告的大型ASP.NET项目。我们正在将所有SQL查询(针对Oracle数据库运行)移动到三个Web服务中。 Web服务按命令,选择和报告查询进行分类。我们必须使用SQL * Server后端将项目的子集部署到与Internet断开连接的多个位置。因此,拥有与数据库的所有连接和Web服务中的查询使应用程序易于管理,我们可以提取报告子集而不必修改代码。该项目使用Serena ChangeMan软件进行源代码管理。
The issue is we have several programmers and they all need check out the web services files to work on their items. We have just implemented branching, but it is slowly becoming a nightmare. We have monthly production deliveries and sometimes items that are supposed to go into the monthly build get held up until next month. The merging has become a manual process.
问题是我们有几个程序员,他们都需要检查Web服务文件来处理他们的项目。我们刚刚实施了分支,但它正逐渐成为一场噩梦。我们有月产量交付,有时候应该进入月度构建的项目会持续到下个月。合并已成为一个手动过程。
I have conduct Internet Searches and I’m surprised that I have not been able to find any good “Best Practice” web services architecture white pages. There are many big companies that must have faced these issues.
我进行了互联网搜索,我很惊讶我找不到任何好的“最佳实践”网络服务架构白页。有许多大公司必须面对这些问题。
Do most large development groups use branching? I did read that Visual Studio Team System Database Edition could provide standard code that will allow the application to connect to different databases. Would purchasing Team System be the best method? Or does anyone know where I can find documentation that will help us address these issues?
大多数大型开发团队都使用分支吗?我确实读过Visual Studio Team System Database Edition可以提供允许应用程序连接到不同数据库的标准代码。购买团队系统会是最好的方法吗?或者有谁知道我在哪里可以找到有助于我们解决这些问题的文档?
Thank you, Lorie
谢谢Lorie
3 个解决方案
#1
2
This problem would seem to be quite independent of the purpose of the software. The issue here is that you have a small, finite number of files that multiple developers will be working with on a daily basis. I do not have experience with Serena ChangeMan software nor TFS other than playing around with it. I do have experience with a couple of version control systems that use a merge/commit model: CVS and Subversion. These are both excellent, free version control systems that are widely used.
这个问题似乎完全独立于软件的目的。这里的问题是,您有一个小的,有限数量的文件,多个开发人员将每天使用这些文件。我没有使用Serena ChangeMan软件和TFS的经验,除了玩它。我确实有一些使用合并/提交模型的版本控制系统的经验:CVS和Subversion。这些都是广泛使用的优秀的免费版本控制系统。
If you are unfamiliar with the merge/commit model, the idea here is that no single developer can "checkout" and lock a file for changes. Everyone can download and make changes to any file. When it is time to commit these changes to the source code database, the repository software will prevent a commit if other changes have been made to the file by another developer. The new version is then downloaded, and in most cases the changes are automatically merged with your changes. You re-test, and then you commit that version. This model is very successful and very scalable.
如果您不熟悉合并/提交模型,那么这里的想法是没有任何一个开发人员可以“签出”并锁定文件以进行更改。每个人都可以下载并更改任何文件。当需要将这些更改提交到源代码数据库时,如果其他开发人员对该文件进行了其他更改,则存储库软件将阻止提交。然后下载新版本,并且在大多数情况下,更改会自动与您的更改合并。您重新测试,然后您提交该版本。该模型非常成功且可扩展性很强。
Having said all of that, even the merge/commit model cannot solve the grief of having a small number of files with a lot of developers making changes to said files. I would recommend splitting your functionality into more web services. Perhaps instead of three, monolithic web services you might create three groups of related web services. I think this, coupled with using a version control system with merge/commit will solve your problems.
说完所有这些之后,即使是合并/提交模型也无法解决由于许多开发人员对所述文件进行更改而导致少量文件的悲痛。我建议将您的功能分成更多的Web服务。也许您可以创建三组相关的Web服务,而不是三个单一的Web服务。我认为这一点,加上使用带有merge / commit的版本控制系统将解决您的问题。
CVS and Subversion servers run on Windows, Mac and Linux. There are a number of clients for each, available on a number of operating systems. These include stand-along clients, Visual Studio plug-ins, and shell plugins. Another plus is that both CVS and Subversion are available from the command line which makes scripting (think automated build) fairly easy.
CVS和Subversion服务器可在Windows,Mac和Linux上运行。每个客户端都有许多客户端,可在许多操作系统上使用。其中包括独立客户端,Visual Studio插件和shell插件。另一个优点是CVS和Subversion都可以从命令行获得,这使脚本(想想自动构建)变得相当容易。
#2
1
Why not segment your logic into individual class files that can be checked out by each developer?
为什么不将您的逻辑划分为可由每个开发人员检出的单个类文件?
#3
0
We use SOA, but we also use SVN which is more merging oriented. Maybe consider a different source control system?
我们使用SOA,但我们也使用更加合并的SVN。也许考虑一个不同的源控制系统?
#1
2
This problem would seem to be quite independent of the purpose of the software. The issue here is that you have a small, finite number of files that multiple developers will be working with on a daily basis. I do not have experience with Serena ChangeMan software nor TFS other than playing around with it. I do have experience with a couple of version control systems that use a merge/commit model: CVS and Subversion. These are both excellent, free version control systems that are widely used.
这个问题似乎完全独立于软件的目的。这里的问题是,您有一个小的,有限数量的文件,多个开发人员将每天使用这些文件。我没有使用Serena ChangeMan软件和TFS的经验,除了玩它。我确实有一些使用合并/提交模型的版本控制系统的经验:CVS和Subversion。这些都是广泛使用的优秀的免费版本控制系统。
If you are unfamiliar with the merge/commit model, the idea here is that no single developer can "checkout" and lock a file for changes. Everyone can download and make changes to any file. When it is time to commit these changes to the source code database, the repository software will prevent a commit if other changes have been made to the file by another developer. The new version is then downloaded, and in most cases the changes are automatically merged with your changes. You re-test, and then you commit that version. This model is very successful and very scalable.
如果您不熟悉合并/提交模型,那么这里的想法是没有任何一个开发人员可以“签出”并锁定文件以进行更改。每个人都可以下载并更改任何文件。当需要将这些更改提交到源代码数据库时,如果其他开发人员对该文件进行了其他更改,则存储库软件将阻止提交。然后下载新版本,并且在大多数情况下,更改会自动与您的更改合并。您重新测试,然后您提交该版本。该模型非常成功且可扩展性很强。
Having said all of that, even the merge/commit model cannot solve the grief of having a small number of files with a lot of developers making changes to said files. I would recommend splitting your functionality into more web services. Perhaps instead of three, monolithic web services you might create three groups of related web services. I think this, coupled with using a version control system with merge/commit will solve your problems.
说完所有这些之后,即使是合并/提交模型也无法解决由于许多开发人员对所述文件进行更改而导致少量文件的悲痛。我建议将您的功能分成更多的Web服务。也许您可以创建三组相关的Web服务,而不是三个单一的Web服务。我认为这一点,加上使用带有merge / commit的版本控制系统将解决您的问题。
CVS and Subversion servers run on Windows, Mac and Linux. There are a number of clients for each, available on a number of operating systems. These include stand-along clients, Visual Studio plug-ins, and shell plugins. Another plus is that both CVS and Subversion are available from the command line which makes scripting (think automated build) fairly easy.
CVS和Subversion服务器可在Windows,Mac和Linux上运行。每个客户端都有许多客户端,可在许多操作系统上使用。其中包括独立客户端,Visual Studio插件和shell插件。另一个优点是CVS和Subversion都可以从命令行获得,这使脚本(想想自动构建)变得相当容易。
#2
1
Why not segment your logic into individual class files that can be checked out by each developer?
为什么不将您的逻辑划分为可由每个开发人员检出的单个类文件?
#3
0
We use SOA, but we also use SVN which is more merging oriented. Maybe consider a different source control system?
我们使用SOA,但我们也使用更加合并的SVN。也许考虑一个不同的源控制系统?