在我们当前的开发中。工作流程有主数据库 - ＆gt; DbMain 。有一个过程采用最新版本的项目并自动在那里部署，然后触发单元测试。因为我们希望在源代码控制中始终具有项目的工作版本，所以每个开发人员都应该确保他检查工作代码并且所有测试都将被传递。
为此，我们决定为具有以下命名约定的每个开发人员创建单独的数据库 - ＆gt; DbMain_ XX （其中 XX 是开发者的首字母）。因此，在签入之前，每个开发人员都要手动将所有更改发布到该数据库并运行单元测试。为此目的设置发布配置很有用，因为它是主发布配置的副本，只有数据库名称的区别。
这将介绍我们将在解决方案中有很多不同的发布配置文件，这非常混乱。
如果我们不将这些配置文件添加到源代码控制中，那么 .sqlproj 文件仍会引用这些文件，因此项目将引用不存在的文件。
所以实际的问题。我是否可以为所有使用变量更改数据库名称的开发人员提供单一发布配置文件？例如 DbName _ $（dev_initials）？或者我们可以让每个开发人员只在本地拥有他们自己的发布配置，它不会破坏项目吗？
更新：
根据Peter Schott的评论：
我可以创建本地发布配置文件，但如果我不将其添加到源代码控制中，那么仍然是sqlproj文件中的条目，但文件本身将不可用。
在本地运行测试至少有两个缺点。第一个是每个人都应该在本地安装SQL Server。我们主要通过虚拟机工作，磁盘空间非常有限。另一件事是开发人员肯定会忘记或不会每次都手动运行测试。有时他们会将更改推送到repo而不构建它或/和运行测试。我们希望避免这种情况，并且＆＃34;赶上＆＃34;尽快失败。
提到的另一种方法是拥有1个公共构建数据库。在我的情况下，我们有一个（DbMain）。所有的开发人员都可以根据需要使用它，但是当2个开发人员同时发布时，我们肯定能够抓住这种情况，并且通过弄清楚究竟出了什么问题可能会造成很多混乱。
答案 0 :(得分：1)
这种事情的常见方法 - 不仅对于SSDT发布配置文件，而且对于一般的配置文件 - 是提交文件的通用版本，其名称类似于library(ggplot2)
col1 = c("red1", "green1")
col2 = c("red4", "green4")
dfs = data.frame(df = c("df1", "df2"), col1, col2 , stringsAsFactors = FALSE)
category_type1 = rep(c("A", "B"), each = 3)
category1 = rep(c(1, 2, 3), 2)
weight1 = c(5, 8, 9, 6, 4, 7)
df1 = data.frame(category_type = category_type1, category = category1, weight = weight1, stringsAsFactors = FALSE)
category_type2 = rep(c("A", "B"), each = 3)
category2 = rep(c(1, 2, 3), 2)
weight2 = c(10, 2, 1, 1, 5 , 7)
df2 = data.frame(category_type = category_type2, category = category2, weight = weight2, stringsAsFactors = FALSE)
for (i in 1:2) {
assign("data", eval(as.name(dfs[i, "df"])))
barColours = c(dfs[i, "col1"], dfs[i, "col2"])
distribution = ggplot(data, aes(x = category, y = weight, fill = category_type)) +
geom_bar(stat = "identity", position = "dodge") +
scale_fill_manual(values = barColours)
assign(paste0(dfs[i, "df"], "_plot"), distribution)
}
df1_plot
df2_plot
，并提供指令。开发人员将文件重命名为DbMain.publish.xml.template - 或其他 - 以及DbMain.publish.xml此文件的本地副本，允许开发人员进行他们想要的任何更改，但继承.gitignore的常用设置该文件的版本。
发布配置文件不需要添加到.template以便在部署时使用，这只是Visual Studio的一个便利，使它们更容易查找和编辑，因此您不需要担心破坏的参考文献。
你想要避免多个开发人员发布到一个共同的“构建”数据库，这是一个令人沮丧的方法。
实际上，您希望将“构建”数据库作为CI流程的一部分发布，这意味着在之后开发人员推动了他们的更改。