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