1

我们有一个包含数百个报告的大型 ASP.NET 项目。我们正在将所有 SQL 查询（针对 Oracle 数据库运行）移动到三个 Web 服务中。Web 服务按命令、选择和报告查询分类。我们必须使用 SQL*Server 后端将项目的子集部署到与 Internet 断开连接的多个位置。因此，在 Web 服务中拥有与数据库的所有连接和查询使应用程序易于管理，我们可以提取报告的子集而无需修改代码。该项目使用 Serena ChangeMan 软件进行源代码控制。

问题是我们有几个程序员，他们都需要检查 Web 服务文件来处理他们的项目。我们刚刚实现了分支，但它正在慢慢变成一场噩梦。我们有每月的生产交付，有时应该进入每月构建的项目被推迟到下个月。合并已成为手动过程。

我进行了 Internet 搜索，但我很惊讶我无法找到任何好的“最佳实践”Web 服务架构白页。有许多大公司一定面临过这些问题。

大多数大型开发小组都使用分支吗？我确实读过 Visual Studio Team System Database Edition 可以提供允许应用程序连接到不同数据库的标准代码。购买 Team System 会是最好的方法吗？或者有谁知道我在哪里可以找到可以帮助我们解决这些问题的文档？

谢谢你，洛里

4

3 回答 3

2

这个问题似乎与软件的目的完全无关。这里的问题是您每天都有多个开发人员将使用的文件数量有限。除了玩弄它之外，我没有使用 Serena ChangeMan 软件或 TFS 的经验。我确实有使用合并/提交模型的几个版本控制系统的经验：CVS和Subversion。这些都是被广泛使用的优秀、免费的版本控制系统。

如果您不熟悉合并/提交模型，这里的想法是没有一个开发人员可以“签出”并锁定文件以进行更改。每个人都可以下载和更改任何文件。当需要将这些更改提交到源代码数据库时，如果其他开发人员对文件进行了其他更改，存储库软件将阻止提交。然后下载新版本，在大多数情况下，更改会自动与您的更改合并。您重新测试，然后提交该版本。这个模型非常成功并且非常可扩展。

说了这么多，即使是合并/提交模型也无法解决拥有少量文件而大量开发人员对所述文件进行更改的痛苦。我建议将您的功能拆分为更多的 Web 服务。也许您可以创建三组相关的 Web 服务，而不是三个单一的 Web 服务。我认为这一点，再加上使用带有合并/提交的版本控制系统将解决您的问题。

CVS 和 Subversion 服务器在 Windows、Mac 和 Linux 上运行。每个都有许多客户端，可在许多操作系统上使用。其中包括独立客户端、Visual Studio 插件和 shell 插件。另一个优点是 CVS 和 Subversion 都可以从命令行获得，这使得脚本（想想自动构建）相当容易。

于 2008-12-09T18:34:56.037 回答
1

为什么不将您的逻辑分割成每个开发人员都可以签出的单独的类文件？

于 2008-12-09T21:05:27.590 回答
0

我们使用 SOA，但我们也使用更面向合并的 SVN。也许考虑一个不同的源代码控制系统？

于 2008-12-09T18:27:51.963 回答