看过其他问题并看不清楚答案.
我们是一个小型开发团队,致力于可以被描述为3个独立的前台"应用程序"(通过asp web的OnlineOrders,TradeManagement winforms app,ASP.NET ReportingSuite).
但无论好坏,这些应用程序中的每一个共享一个中央SQL2005数据库,我们称之为MainDB.它们都使用相同的Orders表结构,Users,Accounts等,每个应用程序都以某种方式使用了相当多的80%的对象.
在TFS中,我曾认为这3个应用程序中的每一个都是独立的项目,包括工作项跟踪,报告等等.似乎工作得很好,我们的"基于代码"的解决方案已经创建.
现在我试图了解如何将MainDB数据库导入TFS源代码控制.我看不出一个明显的方法来做到这一点.
问题是:我是否应该为MainDB创建数据库项目,将模式导出到项目中的脚本中,并将该数据库项目添加到每个TFS项目中的每个解决方案中？
或者我应该为我的数据库项目单独的TFS项目？开发人员必须打开MainDB数据库TFS项目和(例如)TradeManagement TFS项目开放以开发新功能(因为大多数新功能也会涉及一些数据库更改)？似乎非常沉重.
或者只是有一个名为"Everything"的大型TFS项目,并且其中包含代码项目的功能分支,数据库的数据库分支以及可能使用MainDB数据库的任何其他项目？(在img中,假设MainDB脚本位于'Database'文件夹中)
替代文字http://i26.tinypic.com/t7y4bb.png
等人,我很困惑.Codeplex似乎指出通过将所有解决方案放在大单解决方案中来保持简单.这可持续吗？
感谢您的回复,真的很棒.
将数据库视为API的想法很有意思,它就是这样的.数据库来自众多来源,一些内部,一些外部,一些应用程序获取通过另一个应用程序输入的数据.将其作为每个应用程序进出的API控制是一个非常有用的类比,谢谢你.
不支持依赖关系的成本是一个问题,但我认为我们可以足够自律地以有序的方式进行分支.应用程序代码库的分支可能比数据库更复杂 - 我们实际上只是希望源代码控制下的数据库以某种方式满足Sarbannes-Oxley审计要求.
我将不得不考虑更多.
db的水平分区不是我考虑过的.感觉太多的数据库对象被共享以便能够将其切割成水平块 - 我们在几个块中有相同的对象(表/ sprocs等),我认为这会使我们更加困惑.
Ric*_*erg 17
关于像API一样处理数据库的评论是正确的.虽然实现非常不同 - 从源代码构建和部署数据库需要特殊工具,而不仅仅是编译器+ xcopy - 从概念上讲,您的情况与共享公共实用程序库的团队没有什么不同.
幸运的是,这是一个非常好的研究课题.此外,TFS没有什么特别之处; 您可以阅读具有强大分支和合并功能的任何源控制系统的文档,现在大部分都是这样. 实用的Perforce,红豆书(SVN),Eric Sink的博客(Vault)等都有很好的见解.我特别偏爱Laura Wingerd关于代码行的演讲.当然,您也应该阅读最新的TFS指南.
在StackOverflow上,将这些概念付诸实践的问题也出现过几次.这是TFS用户的最佳总体摘要:Team Foundation Server源控制结构 它包含了最重要的行业原则......
......以及一些特定于TFS的怪癖......
(坦率地说,那里的反应有点过于全面.即使你有数十个或数百个分支,也没有必要像修改后的问题那样将它们深深嵌入源代码树中.让一些分支比其他分支更深入.特别令人困惑的是,IMO模糊了大规模源管理和/或路径空间分支新手的读者的关键要点.如果你希望组织中的每个人都遵循"道路规则",那么简单就是金"正如Wingerd所说的那样.)
无论如何,我知道你并没有特别询问分支和合并,但是你布置源代码树的方式对你的整个软件过程有直接的影响.坦率地说,如果在添加数据库项目时没有遵循#1这样的规则,那么您的前端应用程序团队将永远无法独立运行.因此,您的第一个提案($/FrontOfficeDevelopment下的结构)比第二个更接近商标.但你需要走得更远.将3个应用程序+数据库的文件夹在树中更深一层移动.即,给他们一个共同的父母 - 让我们称之为"整合"以匹配其他StackOverflow示例.如果您需要分支,现在可以通过分支此容器在一个自包含的操作中执行此操作; 如果每个应用程序都是团队项目中的顶级文件夹,那将会更加困难.不久你的源代码树看起来就像"TFS Guidance II"图中所描绘的理想......没有巧合:)
$/Everything
|- Integration
|- 3rdPartyAssemblies
|- Database
|- OnlineOrders
|- Code
|- Tests*
|- ReportingSuite
|- Code
|- Tests
|- TeamBuildTypes
|- TfsBuild.proj
|- QuickBuild.targets
|- FullBuild.targets
|- FullBuildAndTest.targets
|- TradeManagement
|- Code
|- Tests
|- Development #1
|- 3rdPartyAssemblies
|- Database
|- etc
|- Release #1
|- 3rdPartyAssemblies
|- Database
|- etc
*如上所示,打破每个应用程序的测试,使各个团队更容易在他们的树上工作.OnlineOrders的人只需要下载OnlineOrders +共享的东西,比如3rdParty和Database,如果你的应用程序非常大或者有几十个/几百个,这很方便.但是,在分支中创建一个顶级Tests文件夹同样有效,如下所示:
|- Integration
|- Database
|- OnlineOrders
|- ...
|- Tests
|- Database
|- OnlineOrders
|- ...
这使得一次运行整个测试套件更加方便,并降低了树的整体深度/复杂性.缺点是你必须在日常工作中更频繁地在树上导航.也许更长期的麻烦,它需要你手工维持一个平行的结构.添加/删除项目,代码重构,部门重组,外包 - 很多东西可以随着时间的推移改变主代码文件夹的布局.如果测试没有更新以匹配,那么你至少会让QA人感到困惑,并且很可能会破坏测试自动化.
您还提出了是否将公司的努力划分为团队项目的问题.好消息是,这个决定与您选择的分支/合并过程完全正交.与构建,报告,Sharepoint工件和(在某种程度上)工作项(与团队项目的概念紧密耦合)不同,TFS源代码控制系统只是一个跨越它们的大树.我碰巧在我的图表中使用了"Everything"项目,因为它更容易绘制 - 而且因为我自己也不喜欢这种策略 - 但实际上并不重要.
然而,将我们迄今为止所学到的知识与TFS的"团队项目"概念相互配合需要一些额外的思考.我承认,从粗略的产品看起来并不明显,"团队项目"最初是做什么的.我只想说它们是真正的大容器.我们来挑选一些熟悉的例子.Windows和Office绝对应该是独立的团队项目 - 它们是在独立的发布计划下开发的,使用非常不同的工程实践,运行大量定制的错误和报告工作流程,完全不兼容的构建系统等等.但是,没有理由将NTFS分开团队和MSPaint团队成为独立的团队项目,即使他们的实际工作从未重叠; Windows 7 SP1和Windows 8开发也不一定要分开,除非下一个版本里程碑也带来了主要的流程变化.
和分支一样,我觉得简单是金色的.一旦你有多个团队项目,许多曾经平凡的任务突然变成了艰难的决定.假设您在数据库sproc中发现了一个主要由其他团队开发的错误.您是否打开了团队项目中的错误(以确保其在QA签收中得到解决),在另一个团队的团队项目中(因为他们将是编码修复程序的那个),或者在特殊的DB中打开团队项目？无论如何,平均开发人员有多少地方可以搜索活动工作项？这只是第一个出现在脑海中的情景; 还有许多功能在项目中无法很好地转换.不幸的是,还有一些功能要求你拆分.如果团队#1想要使用即时合并,但团队#2的开发过程依赖于独占的结账锁,那么在单个团队项目中就不支持.
我现在用了几次"过程"这个词.这真的是它归结为什么.一旦理解了TFS过程模板的概念,团队项目就会更有意义.这是一篇旧的博客文章,我在这篇文章中进行了扩展,得出了一个方便的经验法则:为每个流程模板创建一个团队项目.(当然也有例外;并非所有TFS功能都可以通过模板控制.)白皮书中提供了更多详细信息,提示我的帖子 - 在里面你会找到一个图表,详细说明在/之间支持/不支持的内容个人团队项目.我的猜测是像你这样的小商店不需要很多妥协来适应单一的团队项目模型,如果有的话.
对于仍然对我们最终如何做到这一点感兴趣的人:有一位TFS专家帮忙!
我们为此付出了沉重的代价:将所有解决方案拆分到他们的项目中,将所有项目放入相关的存储桶中,在源目录中包含.sln文件,以便于查找.这是组织事物的合理方式,并且迄今为止已经发挥作用.
<Branch>
Source
Solution files at root
Server Apps Previously “services”, helper apps running on server
App 1
Project 1
Project N
Installer
App 2
Services WCF/Web services providing business operations
App 1
Project 1
Installer
Client Rich client applications, e.g. WinForms, WPF
App 1
Project 1
Installer
Web Server side web applications
App 1
Project 1
Installer
Database All scripts related to database structures and data
Databases
SMOL
AuditAuthentication
…
Servers (Environments?)
Server1.proj
Server2.proj
Common Reusable classes across applications
Communications
Security
….
SharedBin 3rd party binaries
EnterpriseLibrary
…
Docs
Release notes
Help files
Scripts
Deployment
Data Migration
…
System Tests
Functional
Performance
Security
…
这是它在VS中的样子(保护无辜的一些混淆) alt文本http://i39.tinypic.com/whmwsl.jpg
在这种情况下，我会将数据库项目放入单独的项目中，然后从其他项目中引用它。
恕我直言，如果您的数据库（数据库的单个实例或只是通用数据库模式）在多个项目之间共享，那么您需要将数据库模式（或至少其中的大部分）视为暴露给这些项目的接口。该接口/API 需要独立于任何单个项目进行更改控制和版本控制。因此，数据库成为所有这些项目的外部依赖项，就像任何共享库或服务器一样。
现在。您正在使用 TFS。在 TFS 中拥有单独的项目会产生成本。TFS 的分支模型基于带有项目树的单个命名空间。这需要大量的小心和纪律，否则你会搞砸合并等。
除此之外，完全缺乏对项目之间依赖关系的支持。如果您想更改项目之间的依赖关系，则必须将项目分支为依赖项目的子项目（具有我上面提到的所有分支和合并跟踪问题），或者教您的构建系统始终从 TFS 获取正确的版本（我觉得很可怕）。
请注意，如果项目“Everything”的每个部分都需要单独发布/版本控制，则该项目将无济于事。您提到了子项目的“功能分支”等。这将比单独的项目更糟糕，至少是明确的。如果你们都公开同意维护公共数据库项目，那么当您发现需要与所有其他项目团队协商对其进行的每项更改时，就不会感到惊讶了。
所以，最终，这是你的决定。涉及的所有项目是否足够独立，可以将它们作为单独的项目进行版本控制。他们是否会分歧。您是否希望或需要它们出现分歧？是否值得付出额外的工作成本？
而且是在一个完全不同的层面上。您所谈论的只是将代码库垂直划分为多个层——这里是数据库项目（带有数据库模式等），这里是数据访问，这里是业务逻辑，等等......
您是否考虑过水平分区为域级块，每个块都由其数据库模式完成并备份。您的项目不仅依赖于通用数据库模式，还依赖于一个或多个共享模块。他们每个人都会带来自己的数据库脚本部分。
我只是在想这里。我不太确定这是否会更好，或者是否会在实践中发挥作用。任何人都可以分享他或她的意见吗？
