数据库项目和 TFS 如何帮助我们的开发团队？

Question

我刚刚开始在一个非常小的 IT 部门和一个更小的开发团队（包括我在内只有 2 个开发人员）的新公司工作。我们主要为公司开发内部网络应用程序。

现在我的背景是桌面应用程序，所以对于我以前从未开发过 ASP.Net Web 应用程序的我来说，这份工作需要一点学习曲线。目前我们不使用 TFS，但我已经提出了建议，我们将很快采用它。

我也在考虑建议我们将 SQL 数据库转移到数据库项目中，因为目前我们每晚进行备份以保护数据，但所有更新都是手动的，我们连接到数据库并执行查询等。

我不是 DBA，但在我的上一份工作中，我们正在将数据库迁移到数据库项目中，而 DBA 似乎很喜欢这个想法。这样做的好处和潜在的缺点是什么？它会帮助我们在开发完成后更新我们生活环境中的数据库吗？显然我们不想丢失任何数据，只想更新表/存储过程等。

作为一个附带问题，我对 TFS 的了解非常有限，尽管我们将使用它来处理我们的版本控制，是否可以在开发完成后使用 TFS 自动更新我们的实时网站？

对不起，如果这是一个相当广泛的问题，我正在尝试自己研究这个问题，但我想听听实际使用这些产品并做这些事情的人的意见。

谢谢

Answer 1

关于数据库项目：我和我认识的几位 dba 都有过不同的经历。我不确定他们现在应该在哪里，但这可能只是我工作方式的一个功能。部署模型......很困难，可能会导致一些意外行为。如果你去这条路线测试测试测试，以确保你完全了解正在发生的事情。

如果您只是想获得数据库的版本控制，您可以考虑 Red Gate 的SQL Source Control。它看起来很漂亮，并且与 TFS 挂钩。我使用了其中一个早期版本（beta 和 1.0）一段时间，并且对它非常满意。现在我想起来了，我不知道为什么我这里没有它...... ;)

就在 TFS 之外进行部署而言，您绝对可以做到这一点。我们设置了一个构建服务器，这样每当在构建服务器中检查代码时，它就会自动启动以编译并将其部署到我们的一个测试站点。 Look here 获取入门指南。这确实需要在您的网络服务器上进行一些配置才能正确支持，并且文档充其量是参差不齐的。

一旦您对测试区域感到满意，您就可以将某些内容与构建质量的更改挂钩，以便将代码推送到登台甚至生产服务器......或者只是有一个构建设置来重新编译和部署在那里.尽管我不建议以这种方式进行生产推送。不是因为技术问题，而是时间问题。在必要时从一个位置复制/粘贴到生产环境通常要快得多，从而减少停机时间。