我们是一个小型开发团队,致力于可以描述为3个独立的前台应用程序(OnlineOrders通过asp web,TradeManagement winforms应用程序,ASP.NET ReportingSuite).
但是,无论好坏,每个应用程序共享一个中央sql2005数据库,让我们称之为MainDB.他们都使用相同的订单表结构,用户,帐户等,几乎80％的对象以某种方式被每个应用程序使用.
在TFS中,我认为这3个应用程序中的每个都是独立的项目,工作项目跟踪,报告等将给予我们.似乎工作得很好,得到我们的“基于代码”的解决方案.
现在我试图看看我如何将MainDB数据库导入TFS源代码管理.我看不出这样做的一个明显的方法.
问题是：
我应该为MainDB创建一个数据库项目,将模式导出到项目中的脚本中,并将该数据库项目添加到每个TFS项目中的每个解决方案中？
或者我应该有一个单独的TFS项目只是为我的数据库项目？开发人员必须同时打开MainDB数据库TFS项目和(例如)开放的TradeManagement TFS项目开发新功能(因为大多数新功能也将涉及一些数据库更改)？似乎非常沉重.
或者,通常只有一个大型的TFS项目称为“一切”,并且具有代码项目的特征分支,数据库的数据库分支以及可能使用MainDB数据库的任何其他项目. (在img中,假设MainDB脚本位于“数据库”文件夹中)
alt text http://i26.tinypic.com/t7y4bb.png
男人,我很困惑. Codeplex似乎指出通过将所有解决方案放在大单一解决方案上来保持简单.这是可持续的吗？
感谢您的回应,真的很棒.
将数据库视为API的想法很有趣,这是真的.数据库是从许多来源填充的,一些内部的,一些外部的,一些应用程序获取通过另一个应用程序输入的数据.控制它作为每个应用程序进出的API是一个非常有用的类比,谢谢.
不支持依赖关系的代价是一个问题,但我认为我们可以有条不紊地进行有序的分支.应用程序代码库的分支可能比数据库更多地涉及到 – 我们只是希望以某种方式在源代码管理下的数据库满足Sarbannes-Oxley审计要求.
我将不得不再多思考一下.
db的水平分区不是我想到的.感觉像数据库对象的共享太多可以将其划分为水平块 – 我们会在几个块中有相同的对象(表/ sprocs等),我认为这会使我们进一步混淆.
解决方法
幸运的是,这是一个非常好的研究课题.此外,TFS没有什么特别之处;您可以阅读有关具有强大的分支和数据的任何源控制系统的文档.合并功能,现在是大多数功能.实用的Perforce,红豆书(SVN),Eric Sink的博客(Vault)等都有很好的见解.我特别偏袒了Laura Wingerd’s presentation on codelines.自然,你也应该读latest TFS guidance.
在StackOverflow上,将这些概念付诸实践的问题也出现了好几次.这是TFS用户的最佳总体总结：Team Foundation Server Source Control Structure它结合了最重要的行业原则…
>所有分支都是自包含的.分支之间或分支与固定(非分支)位置之间不允许依赖
>分支中的相对路径是不变的
>促销模式是明确定义的,同样适用于所有工程工程：开发 – >整合 – >生产(使用他们的条款作为主要代码;许多其他的是常用的,通常是相同的核心思想)
> 1个整合分支(又名中继,又名主),连接稳定&不稳定的树边.不允许对等合并.
>可变数量的开发分支,取决于团队/功能/重构器之间所需的隔离度
>根据修补程序的频率,是否有任何版本重叠,以及审核要求有多严格,可以发布“分支”分支
>如果您选择检入文档,第三方二进制文件,编译器等辅助资源,则属于分支结构.见规则1.
…以及一些TFS具体的怪癖…
>不要使用工作区映射来破解共享文件的方式. (dunno谁首先写了“指导” – 幸运的是,它不再出现在最新的P& P修订版)
>不要分支/合并到现有分支层次结构的子目录中. (再次,自从首次亮相以来,TFS发布了一些“建议”,尽管我还没有认识到他们跟随它的人很开心)
>不要使用默认的TeamBuildTypes文件夹;像所有代码一样,您的构建脚本应该从上面按照第1-3点
(坦白说,尽管如此,这里的回答已经有点太全面了,即使你有几十个分支,也没有必要像修改后的问题那样将它们嵌入到源代码树中.特别令人困惑的是,IMO掩盖了大量源代码管理和/或路径空间分支新手读者的关键外包,如果希望让组织中的每个人都遵循“道路规则”,简单性就是金色的,“作为Wingerd的短语.)
无论如何,我知道你不是在分析&专门合并,但您排除源树的方式对您的整体软件过程有直接的影响.直言不讳,如果您在添加数据库项目时不遵守#1的规则,那么您的前端应用程序团队将永远无法独立运行.因此,您的第一个提案($/ FrontOfficeDevelopment下的结构)比第二个提案更接近标记.但你需要走得更远.将3个应用数据库的文件夹移动到树中更深一层.即,给他们一个共同的父母 – 让我们称之为“集成”,以匹配其他StackOverflow示例.如果你需要分支,你现在可以通过分支这个容器在一个独立的动作中做到这一点;如果每个应用程序是Team Project中的顶级文件夹,将会更加困难.不久之前,您的源代码树就像“TFS指导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&数据库,如果您的应用程序非常大或数十个/数百个,这是方便的.但是,在分支中创建一个顶级测试文件夹同样有效,如下所示：
|- Integration
|- Database
|- OnlineOrders
|- ...
|- Tests
|- Database
|- OnlineOrders
|- ...
这样可以更方便地一次运行整套测试,并降低树的整体深度/复杂度.在日常工作中,您将不得不更多地浏览树木.也许更麻烦的是长期的,它需要你手动维护一个平行的结构.添加/删除项目,代码重构,部门重组,外包 – 很多事情可以随着时间的推移改变主要代码文件夹的布局.如果测试没有更新以匹配,您将使QA人员至少混淆,并且有可能破坏测试自动化来启动.
您还提出了将您公司的努力划分为团队项目的问题.好消息是,这个决定与您选择的分支/合并过程完全正交.与构建,报告,Sharepoint工件和(在某种程度上)工作项目不同的是,这些工作项目与Team Projects的概念紧密相连,TFS源代码管理系统只是一个跨越它们的大树.我恰好在我的图表中使用了“一切”项目,因为它更容易绘制 – 而且我自己也承认这一策略,但实际上并不重要.
然而,交配我们迄今为止所学到的TFS概念的“团队项目”需要一些额外的想法.我承认,从产品粗略的角度看,“团队项目”是一回事,这一点并不明显.只要说它们是真正的大容器.我们来选一些熟悉的例子. Windows和Office应该是独立的团队项目 – 它们是独立的发行计划开发的,使用非常不同的工程实践,运行大量定制的错误&报告工作流程,完全不兼容的构建系统等.但是,即使实际工作不重叠,也没有什么理由将NTFS团队和MSPaint团队分成单独的团队项目;除非下一个发布的里程碑还带来了重大的流程变化,否则Windows 7 SP1和Windows 8开发也不会被拆分.
与分支一样,我觉得简单是金色的.一旦你有多个团队项目,许多曾经是平凡任务的事情突然变成了艰难的决定.假设您发现数据库sproc中的错误主要由另一个团队开发.您打开了团队项目中的错误(以确保已解决您的QA签收),在另一个团队的团队项目中(因为他们将是修复程序的代码),或者在专门的DB中团队项目？平均开发者有多少地方希望搜索积极的工作项目呢？这只是头脑中的第一个场景;有更多的功能在项目之间不能很好的翻译.不幸的是,还有一些功能需要你拆分.如果团队#1想要使用即时合并,但是团队#2的开发过程依赖于独占结帐锁,这在单个团队项目中根本不被支持.
现在我已经使用了“过程”这个词了.这真的是它归结到的.一旦了解了TFS Process Template的概念,Team Projects就会变得更加有意义.这是一个old blog post,我在这个想法上扩展,导致一个方便的经验法则：每个流程模板创建一个团队项目. (当然有例外;并不是所有的TFS功能都可以通过模板控制.)更多详细信息可在the whitepaper that prompted my post – 内部,您将找到一个图表,详细说明各个团队项目之间/内部不支持的内容.我的猜测是,像您这样的小商店不需要许多妥协,以适应单一团队项目模式(如果有的话).
