Comments
Sort by recent activity
I assume it's the same deal as this?: https://forum.red-gate.com/discussion/86733/red-gate-issues-with-ssms-18-5 Are you on the latest version? / comments
I assume it's the same deal as this?:https://forum.red-gate.com/discussion/86733/red-gate-issues-with-ssms-18-5Are you on the latest version?
Podcasts: check out "You 're dead to me" on BBC Sounds 😉 / comments
Podcasts: check out "You 're dead to me" on BBC Sounds 😉
Thanks for sharing Roseanna, Agree with everything you've mentioned above. Personally I've found it far to easy to get lost in the soon and gloom of Twitter and 24 hour news broadcasts. The last week has been particularly bad. Staying up to date is important, but I've decided to put limits on my social media use and the amount of news that I expose myself to. From now on I'm going to check the news once a day and force myself to spend the rest of my time with my wife and kid and doing the things you mentioned above, whilst avoiding Pandemic news/discussions. 24/7 pandemic news is just too much. / comments
Thanks for sharing Roseanna,Agree with everything you've mentioned above.Personally I've found it far to easy to get lost in the soon and gloom of Twitter and 24 hour news broadcasts. The last week...
There's a lot to unpack here. I'm going to try to avoid prescribing a process. Instead, here are some principles to think about: - Use git. But I think you know that already. You need the superior branching that comes with a DVCS. - Development, for the best part, happens on local DBs and goes into source control BEFORE it gets deployed to any shared environment. Work for different tasks that may need to be deployed independently should be committed to separate source control branches and merged with master when ready to be deployed. - When source code is deployed to a shared environment, you take the ENTIRE BRANCH - you don't cherry pick. Your mental model should be based on developing and testing complete versions of code, to avoid wild west environments and "it works on my machine" problems. - You should avoid multiple long-lived branches, this creates awful merge pain. - You can generally make your life a lot easier by reducing concurrent pieces of work. One good way to do this is to think about Value Stream Mapping and focussing on reducing wait times throughout the process, and prioritising finishing (deploying to prod) current work over starting new work. - Your source control strategy should mirror the reality of how you manage work, otherwise people won't be able to use it effectively. - Adhering to these principles are more important than maintaining your existing processes. I advise you read The DevOps Handbook. If you still want to talk this through, get in touch. I'm not sure a forum post will be enough to help you solve your underlying issues. / comments
There's a lot to unpack here. I'm going to try to avoid prescribing a process. Instead, here are some principles to think about:- Use git. But I think you know that already. You need the superior b...
This sounds like a branching problem to me. Which source control system are you using? Git? TFVC? I'm going to assume git. Because git has sane branching that avoids copying files all over the place. If it was me, I would make your version the master version in git, and I'd create a branch for the forked version. You should now be able to flip between the master and the forked version with a simple git command and avoid needing to create a third directory for the ojects that are already in sync. If you combine this with auto deployment and provisioning capabilities (check out Redgate's SQL Proivision and the SQL Change Automation PowerShell cmdlets) your developers should be able to spin up databases in either the master or the forked version for dev/testing and deploy either version. You now have an awful merge task to perform. That's not easy, but 10 years of forked development will do that to you. The advantage with this approach is that you can gradually resolve your differences over time by updating either the master database and/or the forked database to achieve consistency one object at a time. Eventually, with enough effort, you should be able to fully merge the branches and bin off the fork. / comments
This sounds like a branching problem to me. Which source control system are you using? Git? TFVC?I'm going to assume git. Because git has sane branching that avoids copying files all over the place...
Using the "working folder" option is exactly what I would have suggested. It has been designed for precicely this use case. The button is renamed from "commit" to "save changes" if you use this option. / comments
Using the "working folder" option is exactly what I would have suggested. It has been designed for precicely this use case.The button is renamed from "commit" to "save changes" if you use this option.
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line. That said, any automated solution like that fills me with dread. It feels particularly painful to support/maintain. Much easier to get into the habbit of saving changes in SQL Source Control (using the "working folder" option) and then using the prefered git tool to manage commits/pushes etc. / comments
It's not available out of the box - but it could probably be automated using some sort of DDL triger and the SQL Compare command line.That said, any automated solution like that fills me with dread...
Yes / comments
Yes
1. Have you looked at using a SQL Change Automation project instead of a SQL Source Control project. It's migration script based, rather than disired state-based like SQL Source Control. It basically works exactly like that: https://documentation.red-gate.com/sca/developing-databases 2. If you want to stick with SQL Source Control, you can set up an automated build task using the SQL Change Automation PowerShell cmd-lets: https://documentation.red-gate.com/sca/reference/powershell-cmdlets For example, if you created a new DatabaseReleaseArtifact for each commit, using the latest source control version as the source and the prod DB (or a copy of the prod DB) as the target, you could publish this release artifacts to a shared location. That release artifact will contain: - Copy of source schema - Copy of Target schema- Update script - Human readable diff report with any warnings etc
/ comments
1. Have you looked at using a SQL Change Automation project instead of a SQL Source Control project. It's migration script based, rather than disired state-based like SQL Source Control. It basical...