How can we help you today? How can we help you today?
ben_b
I can share something I have done at three companies using Sql Source Control that has worked brilliantly  but probably only works if there are one or two developers co-located.  At the time we used SVN and TFVC and didn't use branching.  Also, I was pretty strict on one-piece flow. It's not best practice but is so quick and easy to setup and move code around environments. 1.  Hook all your environments up to source control using the 'dedicated' model irrespective of whether you are using shared or dedicated environments.  for me, this included prod. 2.  Develop in your development environment and commit using Sql Source Control 3.  When you want to move the change to a test environment, just use the Get-Latest tab.  Same with production deployments. 4.  If you ever did need to do an emergency hot-fix in prod. Just push to source-control from there and make sure you get the latest on your development environment straight away. Some people may baulk at this haha but I reckon I have done over 3,000 commits and 100's of production deployments using this method without ever running into a problem!! It also means you only ever work in one tool, SSMS.  CI/CD pipelines are all the rage but imo they are not trivial to setup and they are not essential to building great software, especially for very small, tight-knit teams. Also worth noting that this was on Data Warehouse projects and I had created automated tests so I knew early whether my changes would work - the tests just weren't triggered, i had to click a button [image] / comments
I can share something I have done at three companies using Sql Source Control that has worked brilliantly  but probably only works if there are one or two developers co-located.  At the time we use...
0 votes
Hi @gmartin Welcome to the forums.  We had this scenario too. As well as the options listed above, here are some other possible options. 1.  Create SSIS packages that will copy the data over from prod to dev.  This will be a data only refresh. (You can use BIML to make it dynamic)   2.  Backup/Restore from prod every night but also schedule a job to publish/deploy your dev work from source control to the freshly restored copy on your dev server 3.  Create a separate dev database and do your development work using cross database references until they are ready for production.  (not great but can work) 4.  Truncate/Insert Into using linked server 5.  Truncate/Insert Into using a replicated copy of the production database. 6.  Truncate/Insert Into using polybase 7.  Use transactional replication (prod=publisher, dev=subscriber).  You can still do your dev work on the replicated copy. Out of all of these, 7 would prob be the simplest.  Needless to say, pros and cons to all of them. We went for option 1.  We had a really smart developer come in who automated it all for us. "Also, I see things on the Red Gate site about DB Dev Ops.  To be honest, I don't exactly know what that term precisely means.  Any pointers toward educating me on that would also be appreciated." As for this, I have written a post to help people get started with devops:  https://benbrown-sql.com/devops/ Best of luck Ben / comments
Hi @gmartin Welcome to the forums.  We had this scenario too.As well as the options listed above, here are some other possible options.1.  Create SSIS packages that will copy the data over from pro...
0 votes