我应该把在TFS什么地方我的数据库项目？(What place in TFS should I pu

已通过其他问题望去，看不到一个明确的答案。

我们是一个小的开发团队，在什么可以被描述为（通过asp网络，TradeManagement WinForms应用程序，ASP.NET ReportingSuite OnlineOrders）3个独立的前台办公“应用程序的工作。

不过是好还是坏，这些应用程序共享一个中央SQL2005数据库，姑且称之为MainDB。它们都使用相同的订单表的结构，用户，账户等，几乎对象的80％都以某种方式由每个应用程序的使用。

在TFS，我原以为这些应用程序3作为单独的项目，工作项跟踪，报告等，会给我们的。似乎做工精细获得创建了“基于代码的解决方案。

现在，我想知道怎样才能让MainDB数据库到TFS源代码管理。我看不到一个明显的方式做到这一点。

问题是 ：我应该创建MainDB数据库项目，架构导出到脚本的项目，并添加数据库项目到每一个解决方案，每个项目TFS里面？

或者我应该有一个独立的TFS项目只是为我的数据库项目？而一个开发者必须同时打开MainDB数据库TFS项目和（EG）的TradeManagement TFS项目开放开发新的功能（因为大多数新功能将涉及到一些分贝也会发生变化）？似乎非常重手。

或者是它通常只拥有一个庞大的TFS项目，叫做“一切”，并在具有对代码的项目特性分支，并为数据库的数据库分支，并可能使用MainDB数据库中的任何其他项目？（请在图片，假设MainDB脚本是在“数据库”文件夹中）

等人，我很困惑。 Codeplex上似乎指向保持简单通过把里面的大单解决方案的所有解决方案。那是可持续的吗？

感谢您的答复，真是太好了。

治疗作为API有趣的是数据库的想法，真的是这样。该数据库是从许多来源，一些内部，外部的一些人口，一些应用程序中获取数据了，这是通过另一个应用程序的输入。控制它为每个应用程序逢低进出的是一个非常有用的比喻，感谢，一个API。

具有依赖性不支持的成本是一个问题，但我认为我们可以足够的自律做到我们的分支在有条不紊地进行。应用程序代码库的分支很可能是比数据库更复杂 - 我们真的只是想源控制下的数据库以某种方式满足萨班斯 - 奥克斯利法案的审计要求。

我将不得不考虑一些这一点。

DB的水平分区是不是我会考虑的。这感觉就像太多的数据库对象的共享，以便能够把它切成块的水平 - 我们不得不在几个街区，我认为会进一步混淆了我们同样的对象（表/存储过程等）。

Answer 1:

关于治疗的数据库就像一个API的意见是正确的。虽然实现非常不同 - 建筑与部署从源代码数据库也需要特殊的工具，而不仅仅是一个编译器+ XCOPY - 你的情况是没有概念从谁都有一个共同的工具库队不同。

幸运的是，这是一个很好的研究课题。此外，没有什么特别TFS一下; 你可以阅读具有强大的分支和合并功能，这现在是大多数人的任何源控制系统的文档。 实用Perforce公司 ，红豆书（SVN），埃里克库的博客（库）等都有很好的见解。我特别偏爱劳拉Wingerd对代码行演示。当然，你应该阅读最新的TFS的指导了。

这里在计算器上，把这些概念付诸实践的问题也来了好几次。这一个是对TFS用户提供最佳的整体摘要： Team Foundation Server的源代码控制结构它采用了最重要的产业原则...

所有分支是自包含的。允许分支之间没有依赖关系，或者一个支路和固定的（非支化）的位置之间
分支中的相对路径是不变
推广模式的明确界定，并同样适用于所有工程产品：开发 - >集成 - >生产（使用其条款的主要代码行，很多人都在共同使用，通常达同样的核心思想）
1个集成分支（又名干线，又名主）链接树的稳定和不稳定的两侧。没有对等网络合并允许的。
开发分支的变量＃取决于队伍/特征/ refactors之间所需的隔离程度
发布分支的变量＃取决于修补程序的频率，任何版本是否重叠，以及如何严格审计要求
如果您选择签入二次资源，如文件，第三方的二进制文件，编译器等，它们属于分支结构内。请参见规则＃1。

......以及一些TFS特定的怪癖...

不要使用工作区映射破解您的方式左右的共享文件。（不知道谁最先写的“指导意见” - 幸运的是，它不再出现在最新的P＆P修订）
没有分支/合并到现有分支层次结构的子目录。（再次，一些“建议”这是遵循TFS出道以来，尽管我还没有遇到有人谁是幸福的，他们跟着它）
不使用默认的文件夹TeamBuildTypes; 像所有的代码，构建脚本应遵循分＃1-3从上面

（坦率地说，虽然，反应也已经变得有点太全面。即使你有数十或数百个分支机构，没有必要窝他们深深的源代码树中作为修改后的问题一样。有一些分支机构活比别人更深特别混乱，IMO模糊读者谁是新的大规模资源管理和/或路径空间分支的关键外卖一般。简单是金，如果你希望让每个人都在您的组织遵循“道路规则， “作为Wingerd短语吧。）

无论如何，我知道你不是问分支和专门合并，但你布置你的源代码树的方式对你的整体软件过程直接影响。说白了，如果你不按照像＃1的规则，当您添加数据库项目，您的前端应用程序团队将永远，永远能够独立运作。因此，您的第一个提案（结构下图为$ / FrontOfficeDevelopment）比第二更接近大关。但是，你需要走的更远。移动文件夹为3个+应用程序数据库树更深一层。即，给他们一个共同的父 - 姑且称之为“整合”，以配合其他StackOverflow的例子。如果你曾经需要分支，你现在可以通过分支此容器这样做是一个自包含的作用; 会更难如果每个应用程序是在团队项目的顶层文件夹。不久你的源代码树看起来就像在“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
            |- ...

这使得它更方便地在一次运行测试整个套件，并降低了树的整体深度/复杂性。缺点是你必须在日常工作中更经常地浏览这个树。也许更令人不安的长期的，它需要你保持手工并行结构。添加/删除项目，代码重构，部门reorgs，外包 - 很多事情可以改变主代码文件夹的布局随着时间的推移。如果没有更新的测试来搭配，你就会有困惑QA人在最低限度，并破测试自动化像样的机会启动。

您也提出了是否将你的公司的努力为团队项目的问题。好消息是，这一决定是完全垂直于你选择的分支/合并过程。不同于建立，报告，SharePoint项目，以及（在某种程度上）工作项，它们都紧耦合的团队项目的概念，在TFS源代码控制系统仅仅是一个跨越所有这些大树。我碰巧在我的图使用的“一切”的项目，因为它更容易吸引 - 因为我是无可否认的部分到自己的策略 - 但它实际上并不重要。

然而，匹配什么我们到目前为止为“团队项目”的概念TFS了解到需要一些额外的思考。我承认它不是从产品到底什么是“团队项目”确实在第一时间匆匆一瞥明显。我只想说，他们的目的是真正的大容器。让我们挑选一些熟悉的例子。 Windows和Office这绝对是独立的团队项目 - 他们是在独立的发布计划开发的，采用完全不同的工程实践，运行高度定制的bug和报告工作流程，完全不相容的构建系统，等等等等。但是，没有什么理由为NTFS分开团队和团队MSPAINT成独立的团队项目，即使他们的实际工作不会重叠; 也不应的Windows 7 SP1和Windows 8的开发被分割，必然的，除非在下一版本的里程碑，也带来了重大的变化过程中与它一起。

与分支，我觉得简单是金。一旦你有多个团队项目，很多事情，曾经平凡的任务一下子变得艰难的决定。比方说，你会发现在宏主要由另一个团队开发了一个数据库的存储过程中的错误。你在你的团队项目打开的bug（以确保它的解析回你QA签收），在其他球队的团队项目（因为他们将编码修复的那些），或在一个特殊的DB-只团队项目？平均开发商有多少地方预计将搜索活动工作项，反正？这只是突然出现在脑海的第一个场景; 有很多不跨项目很好的转化更多的功能。不幸的是，还需要您的事情分手了一些功能。如果团队＃1希望只使用即时合并，但球队＃2的发展过程依赖于独家结账锁，这根本就不是一个团队项目中的支持。

现在我几次已经使用了“过程”。这真的是它归结为。一旦你理解的概念TFS过程模板，团队项目做很多更有意义。这里有一个旧的博客文章，我对这个想法扩大，导致拇指的一个方便的规则： 每创建流程模板一个团队项目 。（当然也有例外。不是所有TFS功能，可以通过模板来控制）的更多细节，请促使我的职务白皮书 -里面你会发现一个图表，详细说明到底是什么/是不是内/之间支持个人的团队项目。我的猜测是像你这样的一个小商店将不需要很多妥协，以适应单个团队项目的模式，如果有的话。

Answer 2:

对于任何人，我们怎么会做它仍然有兴趣：有一个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（有些混淆，以保护无辜）