You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The EF Core bundle looks to be very helpful for simplifying automated deployment scenarios; however, it's still a bit of a black box as to what is going to happen when the bundle gets executed against a specific server. It would be very helpful to have the bundle generate the SQL script that is about to execute and return that, so that it can be reviewed e.g. by the DBA in a manual approval step in the build pipeline. Once approval is granted, then the bundle gets run for real.
I'm imagining something along the lines of efbundle --dry-run this-needs-approval.sql, which would check the migrations history of the destination database, and write out the to-be-executed migrations to the named file. This could then be picked up and published by the deployment pipeline (such as Azure DevOps or Octopus Deploy) and the build paused until the SQL script is reviewed; then efbundle can be executed without the --dry-run option, and the code will be executed.
https://octopus.com/blog/dbup-database-deployment-automation gives a nice example of how this can already be achieved using DbUp with a more full-featured report on what has changed, so not just the combined SQL script but scripts grouped by migration etc
The text was updated successfully, but these errors were encountered:
This is a great idea and I imagine most developers and DBAs would welcome this change. Other organizations I've worked for required that any migration script be reviewed by a DBA - which, as far as I can tell, isn't possible yet with EF bundle. But it's also something that would be very useful to developers as a gut check before running a script blindly. Thanks for posting this suggestion.
The EF Core bundle looks to be very helpful for simplifying automated deployment scenarios; however, it's still a bit of a black box as to what is going to happen when the bundle gets executed against a specific server. It would be very helpful to have the bundle generate the SQL script that is about to execute and return that, so that it can be reviewed e.g. by the DBA in a manual approval step in the build pipeline. Once approval is granted, then the bundle gets run for real.
I'm imagining something along the lines of
efbundle --dry-run this-needs-approval.sql
, which would check the migrations history of the destination database, and write out the to-be-executed migrations to the named file. This could then be picked up and published by the deployment pipeline (such as Azure DevOps or Octopus Deploy) and the build paused until the SQL script is reviewed; thenefbundle
can be executed without the--dry-run
option, and the code will be executed.https://octopus.com/blog/dbup-database-deployment-automation gives a nice example of how this can already be achieved using
DbUp
with a more full-featured report on what has changed, so not just the combined SQL script but scripts grouped by migration etcThe text was updated successfully, but these errors were encountered: