我刚开始在一个非常小的IT部门和一个更小的开发团队（包括我在内的2个开发人员）中与一家新公司合作。我们主要为公司开发内部Web应用程序。
现在我的背景是在桌面应用程序中，所以这项工作为我提供了一个轻微的学习曲线，以前从未开发过ASP.Net Web应用程序。目前我们不使用TFS，但我提出了建议，这是我们即将采用的。
我也在考虑建议我们将SQL数据库移动到数据库项目中，因为目前我们每晚进行备份以保护数据，但所有更新都是手动的，我们连接到数据库并执行查询等。
我不是DBA，但在我上一份工作中，我们正在将数据库迁移到数据库项目，而DBA似乎喜欢这个想法。这会带来什么好处和潜在的挫折？在开发完成后，它是否有助于我们在现场环境中更新数据库？显然，我们不想丢失任何数据，只是更新表/存储过程等。
作为一个附带问题，我对TFS知之甚少，虽然我们将使用它来处理我们的版本控制，但是一旦开发完成，可以使用TFS自动更新我们的实时网站吗？
对不起，如果这是一个非常广泛的问题，我试图自己研究一下，但我想听听实际使用这些产品并做这些事情的人。
由于
答案 0 :(得分：2)
关于数据库项目：我和我知道的几个dba有过不同的经验。我不确定它们到底应该在哪里，但它可能仅仅是我工作方式的一个功能。部署模型很难，可能会导致一些意外行为。如果你进行这条路线测试测试，以确保你完全了解发生了什么。
如果您只想尝试获取数据库的版本控制，可以考虑使用Red Gate中的SQL Source Control。它看起来很漂亮，并挂钩到TFS。我使用了一个早期版本（beta和1.0）一段时间，并对它非常满意。现在我想到了，我不知道为什么我在这里没有它...;）
就部署TFS而言，你绝对可以做到这一点。我们已经建立了一个构建服务器，以便在构建服务器中检查代码时自动进行编译并将其部署到我们的一个测试站点。 Look here有一本入门书可以帮助你入门。这确实需要在您的Web服务器上进行一些配置以正确支持，并且文档最多也是不稳定的。
一旦您对测试区域感到满意，您可以将某些内容挂钩到构建质量的更改中，以便将代码推送到暂存甚至是生产服务器......或者只是让构建设置重新编译并部署到那里。虽然我不建议以这种方式进行生产推动。不是因为技术问题，而是时间问题。在必要时从一个位置复制/粘贴到生产通常要快得多，从而限制了停机时间。