It also gives me the chance to really build in confidence that sqlpackage.exe will work and that I can trust it. This means that the most well tested part of my development process is that bit that is often seen as the most risky (i.e. I use the same script to drive sqlpackage.exe for my local instance that I use on the CI server and other environments to deploy changes and generate change scripts. This one is what I get most excited about (it really really does!). By running in a command window I get to see exactly what changes are happening and if I see the amount of things being re-deployed every time I can do something about it rather than the changes being hidden, again unless I really go looking for it. If there is an issue like you have a default constraint with a definition in SSDT that SQL changes when it store it (such as adding brackets around things) then it will be constantly re-deployed. I often sit waiting after it has finished and then have to click around for the errors - this isn't a moan about the ui, I am just more comfortable with a command line and a bit of console colouring! Benefit #3 - Monitor redeployments
I see quickly and brightly any errors or warnings, I don't really like the publish dialogue in SSDT because it sort of sits at the bottom and doesn't shout when it is finished. If I want to add a variable or change a parameter then I can do it and it is straight forward. I know exactly when a deploy is going to happen and I know exactly what options it will use. This has a number of benefits: Benefit #1 - Simplicity Watch the powershell script and if it deployes successfully, continue my work Alt+Tab to my powershell session and run the deploy script Build the project, ensure there are no errors
Install ssdt with visual studio 2015 code#
Write my code in Visual Studio / SSDT (New code and living the refactoring dream) Write a powershell script that calls sqlpackage.exe to deploy a dacpac to my dev instance It occurred to me pretty early on in my SSDT usage that publishing through visual studio wasn't really the way I wanted to do my development so what I do is:
The second variation I particularly enjoy because I have always though that what I want is a computer that I can think something and it will do it - I guess we are a little way off but one day hopefully that will be possible. I see questions pretty regularly on stack overflow and the ssdt msdn forum that is some variation on “I am doing a publish through visual studio and it doesn't quite do what I want” or “I want to publish the database when I press F5 except when I don't want it to publish”. I dont use the Visual Studio SSDT Publish
0 kommentar(er)
