【问题标题】:EF7 Code first -> SSDT package -> Production Server DeploymentsEF7 代码优先 -> SSDT 包 -> 生产服务器部署
【发布时间】:2016-10-19 00:10:47
【问题描述】:

我正在尝试围绕新的 ASP.NET Core / EF7 应用程序设置持续交付流。

我想使用 Code First EF7 生成和更新我的本地开发数据库,​​然后将更改导入我的 SSDT 数据库项目。从那里我计划在将 webapp 部署到我的 Azure 应用服务时使用带有 dbSqlPackage 提供程序的 MSDeploy 来更新我的 Azure SQL prod db 并进行任何更改。 https://msdn.microsoft.com/en-us/library/hh550081(v=vs.103).aspx

另外请注意,我将进行某种 preprod 部署步骤,在此我对 preprod 系统进行一些测试,然后再无意识地将数据库更新部署到生产环境。

我的问题是 - 我如何在本地 devbox 上自动执行更新 SSDT 项目以反映我的本地开发数据库的步骤?我可以从数据库到 SSDT 项目进行手动 SSDT 比较,这将更新 SSDT 项目 sql 文件。我正在查看 SQLProject.exe,但据我所知,它只会创建 dacpac 或发布到数据库。

有人知道自动化此步骤的方法吗?

【问题讨论】:

    标签: entity-framework visual-studio-2015 sql-server-data-tools continuous-deployment


    【解决方案1】:

    我认为,鉴于您的设置,我会考虑 EF 迁移而不是 SSDT,特别是考虑到您使用的是 EF7 并且迁移就像梅毒一样,不像以前那样尴尬。

    假设您不想进行 EF 迁移,没有简单的方法可以从已部署的数据库中自动生成 .sqlproj 和关联的 .sql 文件;但如果您不关心数据库项目本身,使用 sqlpackage - 或您自己在 DacFX 之上的代码 - 从您部署的数据库生成 .dacpac,然后使用 那并不是太难 作为您通过其他环境推广的人工制品。

    至于管理 pre-prod / prod 隔离,有很多方法可以做到这一点,包括但不限于 VSTS Release Management - 它内置了用于部署到 Azure SQL DB 的任务。

    【讨论】:

    • 我得出了同样的结论 - 从长远来看,使用 SQLPackage 工具创建一个 dacpac,然后将其签入 Sourcecontrol,而不用打扰 SSDT 项目。如果在应用 DACPAC 时出现问题,请返回 EF 并在配置中修复它,或者在迁移中修复它(丑陋)。虽然现在,只是为了关注数据库,我将手动维护 SSDT 中间步骤。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-03-26
    • 1970-01-01
    • 2012-05-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多