Comments
Sort by recent activity
What will happen to the existing SQL Source Control (SoC) and DLM Automation (DLMA) story with DlmDatabaseReleases etc?
Will that story still exist? What will happen for existing users who use SoC and (for example) the DLM Automation PS scripts and/or VSTS/Octopus plugins?
When my customers look at the options (typically SoC+dlma, RR, SSDT or open source script runner), it's the SoC + DLMA story that most want.
For reference, most of my customers are generally early in DevOps adoption, reasonable sized teams doing plenty of SQL Server dev, experiencing issues managing changes (hence moving to migrations-first strategy sounds like it will add complications) and wanting to move towards automated build/deploy but failing and in need of a simple solution. 100% automation isn't necessarily the top priority but simplifying dev processes, change management and mostly automated deploys is - they are happy to be lean and try to solve 80% of the issues with 20% of the effort and they like simple solutions. For these ppl SoC + DLMA is a good fit - and DLMA is a very important part of that.
Should I be steering them away from SoC/DLMA? / comments
What will happen to the existing SQL Source Control (SoC) and DLM Automation (DLMA) story with DlmDatabaseReleases etc?
Will that story still exist? What will happen for existing users who use SoC ...
I'm having the same issue. I have reproduced it on a VM on my laptop and I have a snapshot you can play with when I'm next in Cambridge. Works in SSMS 2014 but not 2017.
Guess I'll have to use old SSMS for my demo today. as don't have time to follow all steps above. :-( / comments
I'm having the same issue. I have reproduced it on a VM on my laptop and I have a snapshot you can play with when I'm next in Cambridge. Works in SSMS 2014 but not 2017.
Guess I'll have to use old ...
Sounds good! / comments
Sounds good!
Command line.
> git push
I know. / comments
Command line.
> git push
I know.
Apologies, just saw the notification.
Well you could write your own PowerShell to call the SQL Compare command line to do all the things, and then wrap that into some higher level orchestrated process using Octopus or similar.
Or you could buy a licence. No point reinventing the wheel. SQL Compare does not have email functionality because that's not how it's designed to be used.
If you want a full pipeline orchestration solution with email notifications the tool Redgate provides is DLM Automation, which plugs into the likes of Jenkins, Octopus, VSTS etc and should give you what you need. / comments
Apologies, just saw the notification.
Well you could write your own PowerShell to call the SQL Compare command line to do all the things, and then wrap that into some higher level orchestrated proc...
(But you cannot trigger emails directly from SQL Compare.) / comments
(But you cannot trigger emails directly from SQL Compare.)
I recommend using something like Octopus Deploy to orchestrate your deployments. You can add steps to call Redgate to generate diff reports/upgrade scripts, trigger emails pre/post deployment, carry out a manual review of diff reports, and execute scripts as required.
Octopus Deploy: https://octopus.com/
Integrating Octopus and Redgate DLM Automation (a PowerShell interface for SQL Compare and other RG tools): https://documentation.red-gate.com/display/DLMA2/Octopus+Deploy+step+templates+reference / comments
I recommend using something like Octopus Deploy to orchestrate your deployments. You can add steps to call Redgate to generate diff reports/upgrade scripts, trigger emails pre/post deployment, carr...
Sorry, I won't be making it to Summit this year. One trip too many. Have fun! / comments
Sorry, I won't be making it to Summit this year. One trip too many. Have fun!
Assuming you are using shared model and that you are looking at the objects listed in the commit tab. If that assumption is incorrect please disregard the rest of this answer an clarify.
Short answer: No. This list is calculated by comparing dev database to source control and the info about who committed what is pulled from he default trace.
Longer answer: You could set up an automated SQL Compare job using SQL Compare command line to create a report of the differences between source control and dev database, but this will not have info about who made what changes unless you also cross-reference with default trace, which sounds hard.
My recommendation: Switch to the dedicated model. Then this problem probably mostly goes away. / comments
Assuming you are using shared model and that you are looking at the objects listed in the commit tab. If that assumption is incorrect please disregard the rest of this answer an clarify.
Short answ...
No worries, glad to help.
And I'd be interested to know why the dedicated model is impossible with your existing constraints. I've not yet found any technical constraints that cannot be resolved and I'm pretty sure it is impossible to be agile with a shared database and more than 3 developers.
Alex / comments
No worries, glad to help.
And I'd be interested to know why the dedicated model is impossible with your existing constraints. I've not yet found any technical constraints that cannot be resolved an...