我应该将我的数据库项目放在 TFS 的哪个位置? [英] What place in TFS should I put my database project in?
问题描述
浏览了其他问题，但没有看到明确的答案.
Have looked through the other questions and can't see a clear answer to this.
我们是一个小型开发团队，致力于开发 3 个独立的前台应用程序"(通过 asp web 的在线订单、TradeManagement winforms 应用程序、ASP.NET ReportingSuite).
We are a small development team, working on what could be described as 3 separate front-office 'applications' (OnlineOrders via asp web, TradeManagement winforms app, ASP.NET ReportingSuite).
无论好坏，这些应用程序中的每一个都共享一个中央 SQL2005 数据库，我们称之为 MainDB.它们都使用相同的 Orders 表结构、Users、Accounts 等，几乎 80% 的对象都以某种方式被每个应用程序使用.
However for better or worse, each of these apps share one central SQL2005 database, let's call it MainDB. They all use the same Orders table structure, the Users, the Accounts etc., pretty much 80% of the objects are used in some way by each of the apps.
在 TFS 中，我曾认为这 3 个应用程序中的每一个都是独立的项目，工作项跟踪、报告等将为我们提供.创建我们的基于代码的"解决方案似乎工作正常.
In TFS, I had thought that each of these 3 apps as being seperate Projects, with the Work Item tracking, reporting etc that would give us. Seemed to work fine getting our 'code based' Solutions created.
现在我想看看如何将 MainDB 数据库导入 TFS 源代码管理.我看不到明显的方法来做到这一点.
Now I'm trying to see how I can get the MainDB database into TFS Source Control. I can't see an obvious way to do this.
问题是:我是否应该为 MainDB 创建一个数据库项目，将模式导出到项目中的脚本中，然后将该数据库项目添加到每个解决方案中，在每个 TFS 项目中?
Question is: Am I supposed to create a database project for MainDB, export the schema into scripts in the project, and add that database project into each Solution, inside each TFS Project?
或者我应该为我的数据库项目创建一个单独的 TFS 项目吗?开发人员必须同时打开 MainDB 数据库 TFS 项目和(例如)TradeManagement TFS 项目才能开发新功能(因为大多数新功能也会涉及一些数据库更改)?看起来很重手.
Or should I have a separate TFS Project just for my database project? And a developer would have to open both the MainDB database TFS Project and (eg) the TradeManagement TFS Project open to develop a new feature (as most new features will involve some db changes too)? Seems very heavy handed.
或者，通常只有一个名为Everything"的大型 TFS 项目，其中包含代码项目的功能分支、数据库的数据库分支以及可能使用 MainDB 数据库的任何其他项目?(在 img 中，假设 MainDB 脚本位于Database"文件夹中)
Or is it common to just have one massive TFS Project, called 'Everything', and within that have feature branches for the code projects, and a database branch for the database, and any other projects that might use the MainDB database? (in the img, assume MainDB scripts are in the 'Database' folder)
等等.伙计，我很困惑.Codeplex 似乎指向通过将所有解决方案放在大型单一解决方案中来保持简单.这是可持续的吗?
etc. Man, I am confused. Codeplex seems to point to keeping it simple by putting all solutions inside on big single solution. Is that sustainable?
感谢您的回复，真的很棒.
Thanks for the responses, really great.
将数据库视为 API 的想法很有趣，确实如此.数据库由许多来源填充，一些是内部的，一些是外部的，一些应用程序获取通过另一个应用程序输入的数据.将其作为每个应用程序进出的 API 进行控制是一个非常有用的类比，谢谢.
The idea of treating the database as an API is interesting, it is really like that. The database is populated from numerous sources, some internal, some external, some apps get data out that was input via another app. Controlling it as an API that each app dips in and out of is a very helpful analogy, thanks for that.
不支持依赖的成本是一个问题，但我认为我们可以有足够的纪律性以有序的方式进行分支.应用程序代码库的分支可能比数据库更复杂——我们真的只是希望数据库以某种方式进行源代码控制，以满足 Sarbannes-Oxley 审计要求.
The cost of having no support for dependencies is a concern, but I think we can be disciplined enough to do our branching in an orderly manner. The branching of the app codebase is likely to be more involved than the database - we really just want the database under source control in some way to satisfy Sarbannes-Oxley audit requirements.
我将不得不对此进行更多思考.
I will have to think some more on this.
数据库的水平分区不是我考虑过的.感觉共享了太多的数据库对象而无法将其切成水平块 - 我们将在几个块中拥有相同的对象(表/sprocs 等)，我认为这会进一步混淆我们.
The horizontal partitioning of the db isn't something I'd considered. It feels like too much of the database objects are shared to be able to chop it into horizontal blocks - we'd have the same objects (tables/sprocs etc) in several blocks which I think would confuse us further.
推荐答案
关于将数据库视为 API 的评论是正确的.虽然实现是非常不同的——构建 &从源代码部署数据库需要特殊工具，而不仅仅是编译器 + xcopy —— 从概念上讲，您的情况与共享通用实用程序库的团队没有什么不同.
The comment about treating the database like an API is right on. While the implementation is very different -- building & deploying a database from source code requires special tools, not just a compiler + xcopy -- your situation is conceptually no different from teams who share a common utility library.
幸运的是，这是一个经过深入研究的主题.此外，TFS 没有什么特别之处.您可以阅读任何具有强大分支和功能的源代码控制系统的文档.合并功能，现在是其中的大部分.Practical Perforce、红豆书 (SVN)、Eric Sink 的博客 (Vault) 等都有很好的见解.我特别喜欢 Laura Wingerd 关于代码线的演示.当然，您也应该阅读最新的 TFS 指南.
Luckily, this is a very well researched topic. Furthermore, there's nothing particular to TFS about it; you can read the documentation for any source control system with robust branching & merging functionality, which by now is most of them. Practical Perforce, the Red Bean book (SVN), Eric Sink's blog (Vault), etc all have good insights. I'm particularly partial to Laura Wingerd's presentation on codelines. Naturally you should read the latest TFS guidance too.
在 StackOverflow 上，将这些概念付诸实践的问题也多次出现.这是 TFS 用户最好的总体总结:Team Foundation Server 源代码控制结构 它融合了最重要的行业原则...
Here on StackOverflow, the question of putting those concepts into practice has also come up several times. This one is the best overall summary for TFS users: Team Foundation Server Source Control Structure It incorporates the most important industry principles...
- 所有分支都是自包含的.分支之间或分支与固定(非分支)位置之间不允许存在依赖关系
- 分支内的相对路径是不变的
- 推广模型定义明确，同样适用于所有工程工件:开发 ->整合 ->生产(将它们的术语用于主要代码行；许多其他术语是常用的，通常相当于相同的核心思想)
- 1 个集成分支(又名 Trunk，又名 Main)，它连接了 stable &树的不稳定的一面.不允许点对点合并.
- 根据团队/功能/重构之间所需的隔离程度，可变的 Dev 分支数量
- 根据修补程序的频率、是否有任何版本重叠以及审计要求的严格程度，可变的发布分支数量
- 如果您选择检入辅助资源，如文档、第 3 方二进制文件、编译器等，它们属于分支结构.见规则#1.
...以及一些 TFS 特定的怪癖...
...along with some TFS specific quirks...
- 不要使用工作区映射来破解共享文件.(我不知道是谁先写了这个指导"——幸运的是它不再出现在最新的 P&P 修订版中)
- 不要分支/合并到现有分支层次结构的子目录中.(再说一次，自 TFS 首次亮相以来，就遵循了一些建议"，尽管我还没有遇到过很高兴他们遵循了它的人)
- 不要使用默认的 TeamBuildTypes 文件夹；像所有代码一样，您的构建脚本应该遵循上面的 #1-3 点
(坦率地说，那里的回复有点太了.即使你有几十或几百个分支，也没有必要像修改后的那样将它们嵌套在源代码树的深处问题确实如此.让一些分支比其他分支活得更深尤其令人困惑，IMO 掩盖了对大规模源管理和/或路径空间分支不熟悉的读者的关键要点.如果您希望让每个人都参与其中，那么简单就是黄金组织遵守道路规则"，正如温杰德所说.)
(Frankly, though, the responses there have gotten a little too comprehensive. Even if you have dozens or hundreds of branches, there's no need to nest them as deeply inside the source tree as the revised question does. Having some branches live deeper than others is especially confusing, IMO obscuring the key takeaways from readers who are new to large scale source management and/or path-space branching in general. Simplicity is golden if you hope to get everyone in your organization to follow the "rules of the road," as Wingerd phrases it.)
无论如何，我知道你不是在问分支和;专门合并，但是您布置源代码树的方式对您的整个软件过程有直接影响.坦率地说，如果您在添加数据库项目时不遵循 #1 等规则，您的前端应用团队将永远能够独立运作.因此，您的第一个提案(在 $/FrontOfficeDevelopment 下描绘的结构)比第二个更接近标记.但你需要走得更远.将 3 个应用程序 + 数据库的文件夹在树中更深一层.即，给他们一个共同的父母——我们称之为整合".以匹配其他 StackOverflow 示例.如果您需要分支，现在可以通过分支此容器在一个独立的操作中执行此操作；如果每个应用程序都是团队项目中的顶级文件夹，那就更难了.不久之后，您的源代码树将看起来就像TFS 指南 II"中描绘的理想一样.图表...不是巧合:)
Anyway, I know you weren't asking about branching & merging specifically, but the way you lay out your source tree has direct implications for your overall software process. Bluntly, if you don't follow rules like #1 when you add the database project, your front-end app teams will never, ever be able to function independently. As such, your first proposal (the structure pictured under $/FrontOfficeDevelopment) is much closer to the mark than the second. But you need to go farther. Move the folders for the 3 apps + database one level deeper in the tree. I.e., give them a common parent -- let's call it "Integration" to match the other StackOverflow example. Should you ever need to branch, you can now do so in one self-contained action by branching this container; would be much harder if each app was a top-level folder in the Team Project. Before long your source tree will look just like the ideals pictured in the "TFS Guidance II" diagrams...no coincidence :)
$/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 &数据库，如果您的应用程序非常大或有几十个/数百个，这很方便.但是，在分支内创建一个顶级 Tests 文件夹同样有效，如下所示:
*Breaking up your tests per-app, as shown above, makes it easier for individual teams to work on their slice of the tree. The OnlineOrders guys only need to download OnlineOrders + shared stuff like 3rdParty & Database, which is convenient if your apps are very large or there are dozens/hundreds of them. However, it's equally valid to make one top level Tests folder inside the branch as shown below:
|- Integration
|- Database
|- OnlineOrders
|- ...
|- Tests
|- Database
|- OnlineOrders
|- ...
这使得一次运行整个测试套件更加方便，并降低了树的整体深度/复杂性.缺点是您必须在日常工作中更频繁地在树上导航.也许长期更麻烦的是，它需要您手动维护并行结构.添加/删除项目、代码重构、部门重组、外包——随着时间的推移，很多事情都会改变主代码文件夹的布局.如果测试未更新以匹配，您至少会混淆 QA 人员，并且很可能会启动损坏的测试自动化.
This makes it more convenient to run your entire suite of tests at once and reduces the overall depth/complexity of the tree. Downside is you'll have to navigate around the tree more often during everyday work. Perhaps more troubling long-term, it requires you to maintain a parallel structure by hand. Adding/removing projects, code refactoring, departmental reorgs, outsourcing -- lots of things can change the layout of the main code folders over time. If Tests isn't updated to match, you'll have confused QA people at minimum, and a decent chance of broken test automation to boot.
您还提出了是否将贵公司的工作划分为团队项目的问题.好消息是这个决定与您选择的分支/合并过程完全正交.与构建、报告、Sharepoint 工件和(在某种程度上)工作项都与团队项目的概念紧密耦合不同，TFS 源代码控制系统只是一棵跨越所有这些的大树.我碰巧用了一个一切"在我的图表中进行项目，因为它更容易绘制 - 而且因为我本人确实偏向于该策略 - 但实际上并不重要.
You also raised the question of whether to divide your company's efforts into Team Projects. The good news is that this decision is totally orthogonal to the branch/merge process you choose. Unlike builds, reports, Sharepoint artifacts, and (to some degree) work items, which are all tightly coupled to the notion of Team Projects, the TFS source control system is simply one big tree that spans them all. I happened to use an "Everything" project in my diagram because it was easier to draw -- and because I'm admittedly partial to that strategy myself -- but it actually doesn't matter.
尽管如此，将我们迄今为止学到的知识与团队项目"的 TFS 概念相结合，需要一些额外的思考.我承认，粗略地看一下产品并不能看出什么是团队项目".首先是.可以说它们旨在成为非常大的容器.让我们挑一些熟悉的例子.Windows 和 Office 绝对应该是独立的团队项目——它们是按照独立的发布时间表开发的，使用非常不同的工程实践，运行高度定制的错误 &报告工作流程、完全不兼容的构建系统等.然而，即使他们的实际工作从不重叠，也没有理由将 NTFS 团队和 MSPaint 团队分成单独的团队项目；Windows 7 SP1 和 Windows 8 的开发也不应该分开，除非下一个发布里程碑也随之带来重大的流程变化.
Nevertheless, mating what we've learned so far to the TFS concept of a "Team Project" requires some extra thought. I'll admit it's not apparent from a cursory look at the product what the heck a "Team Project" does in the first place. Suffice to say they are intended to be really big containers. Let's pick some familiar examples. Windows and Office should definitely be separate Team Projects -- they are developed on independent release schedules, using very different engineering practices, running heavily customized bug & reporting workflows, totally incompatible build systems, etc etc. However, there's little reason to separate the NTFS team and the MSPaint team into separate Team Projects even if their actual work never overlaps; nor should Windows 7 SP1 and Windows 8 development be split, necessarily, unless the next release milestone is also bringing major process changes along with it.
与分支一样，我觉得简单是金.一旦你有多个团队项目，许多曾经是平凡任务的事情突然变成了艰难的决定.假设您在主要由另一个团队开发的数据库 sproc 中发现了一个错误.你是在你的团队项目中打开错误(以确保它被解决回给你以供 QA 签核)，在另一个团队的团队项目中(因为他们将是编码修复的人)，还是在一个特殊的数据库中?团队项目?无论如何，一般开发人员希望在多少地方搜索活动的工作项?这只是我想到的第一个场景；还有很多功能不能很好地跨项目转换.不幸的是，还有一些功能要求您将其拆分.如果团队 #1 想要使用即时合并，但团队 #2 的开发过程依赖于独占签出锁，那么这在单个团队项目中是不受支持的.
As with branching, I feel simplicity is golden. Once you have multiple Team Projects, many things that were once mundane tasks suddenly become tough decisions. Let's say you find a bug in a database sproc that's primarily developed by another team. Do you open the bug in your team project (to ensure it's resolved back to you for QA signoff), in the team project of the other team (since they'll be the ones coding the fix), or in a special DB-only team project? How many places is the average developer expected to search for active work items, anyway? That's just the first scenario that popped into mind; there are many more features that don't translate well across projects. Unfortunately, there are also some features that require you to split things up. If team #1 wants to use just-in-time merging but team #2's development process relies on exclusive checkout locks, that's simply not supported within a single team project.
我用过过程"这个词现在几次.归根结底就是这样.一旦您理解了 TFS 流程模板的概念，团队项目更有意义.这是旧博文 在这里我扩展了这个想法，得出了一个方便的经验法则:为每个流程模板创建一个团队项目.(当然也有例外；并非所有 TFS 功能都可以由模板控制.)更多详细信息请参见 促使我发表这篇文章的白皮书 -- 在里面你会找到一个图表，详细说明在各个团队项目中/之间支持/不支持的内容.我的猜测是像您这样的小商店不需要很多妥协来适应单个团队项目模型(如果有的话).
I've used the word "process" a few times now. That's really what it comes down to. Once you understand the concept of a TFS Process Template, Team Projects make a lot more sense. Here's an old blog post where I expand on this idea, leading to a handy rule of thumb: create one team project per process template. (Of course there are exceptions; not all TFS features can be controlled by templates.) More details are available in the whitepaper that prompted my post -- inside you'll find a chart detailing exactly what is/isn't supported within/between individual team projects. My guess is a small shop like yours won't require many compromises to fit the single Team Project model, if any.
这篇关于我应该将我的数据库项目放在 TFS 的哪个位置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
