以编程方式查找自上次良好构建以来的 TFS 更改
我在 TFS 中有多个分支(开发、测试、阶段),当我将更改合并到测试分支时,我希望自动构建和部署脚本找到所有更新的 SQL 文件并将它们部署到测试数据库。
我想我可以通过查找自上次良好构建以来与构建相关的所有变更集、查找变更集中的所有 sql 文件并部署它们来做到这一点。 但是,出于某种原因,我似乎没有与构建关联的变更集,因此我的问题是双重的:
1)如何确保变更集与特定构建关联?
2)如何获取自上次良好构建以来分支中已更改的文件列表? 我有最后一次成功构建的构建,但我不确定如何在不检查变更集的情况下获取文件(如上所述,与构建无关!)
I have several branches in TFS (dev, test, stage) and when I merge changes into the test branch I want the automated build and deploy script to find all the updated SQL files and deploy them to the test database.
I thought I could do this by finding all the changesets associated with the build since the last good build, finding all the sql files in the changesets and deploying them. However I don't seem to be having the changeset associated with the build for some reason so my question is twofold:
1) How do I ensure that a changeset is associated with a particular build?
2) How can I get a list of files that have changed in the branch since the last good build? I have the last successfully built build but I'm unsure how to get the files without checking the changesets (which as mentioned above are not associated with the build!)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
谢谢斯科特,
过了一段时间我找到了一个很好的方法来管理这个问题。
基本上我创建了一个任务,它获取与构建相关的当前变更集(我的问题的第一点不是问题),然后循环它们寻找 .sql 文件。 一旦我有了这些列表,我就可以创建一个更改脚本或针对目标数据库执行它们。
代码看起来像这样:
ProcessChangeSet 中的代码看起来像
但是如果有人想要,我很乐意为他们提供完整的代码。 确保存储过程在整个系统中同步。 这只会让架构更改在我的数据库中手动管理,我很乐意这样做。
Thanks Scott,
After a while I found a nice way to manage this.
Basically I created a task which gets the current changesets associated with the build (point 1 of my question is not an issue) and then loop through them looking for .sql files. Once I have a list of those I can create a change script or execute them against the target database.
The code looks something like this:
and the code inside ProcessChangeSet looks like
But if anyone wants I'm happy to give them the complete code. Makes making sure stored procedures are in sync across the system. This only leaves schema changes to manually manage within my database which I'm happy to do.
所以我可以理解这种方法的直观吸引力,但我认为这不是正确的方法。
一方面,这会很困难。 但第二个问题是TFS没有很好的方法来记录部署数据。
对于第一个问题,我不确定这意味着什么。 对于第二个问题,您可以使用构建标签和 tf 历史记录今天已更改文件的列表。
作为替代方案,您可以重新考虑如何管理 SQL 更改。 我使用一种低技术含量的方法将当前挂起的更改保留在一个目录中,然后在部署后将文件移动到另一个目录。 可以通过在数据库中保留部署历史表来增强此方法。 您可能还想研究 vsts DB 添加,当前的 CTP 在管理数据库更改方面有许多新功能。 我还听说 Red Gate 也有很好的数据库管理工具。
So I can understand the intuitive appeal of this approach, but I don't think it's the right way to go.
For one thing it's going to be difficult. But the second problem is that TFS doesn't have a good way to record deployment data.
For the first question, I'm not sure what that means. For the second question you can use the build labels and tf history today list of the changed files.
As an alternative, you could reconsider how you want to manage SQL changes. I use a low-tech method of keeping the current pending changes in one directory, and then after deploying moving the files to a different directory. This method can be enhanced by keeping a deployment history table in the database. You may also want to look into vsts DB addition, the current CTP has a lot of new features around managing database changes. I also hear that Red Gate has nice database management tools as well.