Comments
Sort by recent activity
Generally it was fantastic. RR was much much quicker to refresh than SQL Source Control and the customer was *very* impressed.
However, the customer still didn't really understand what was going on. I mostly had to click the buttons and say "I know you don't understand this yet, let me just generate the project for you then I'll explain how it works".
Generally it just was not clear what the target DB was supposed to be. The CI db? the Prod db? Why do I need to put this in now?
And the Baseline scripts just existed without any real explanation. And when asked about the 'programmable objects' decision the customer had no idea what that was, let alone how to make a decision about it.
So generally the experience was good - but they still needed me with them to walk them through it.
Let me know if you want to chat in more detail. / comments
Generally it was fantastic. RR was much much quicker to refresh than SQL Source Control and the customer was *very* impressed.
However, the customer still didn't really understand what was going on...
Great timing. I'll try it tomorrow at a bank in Brussels. ;-) / comments
Great timing. I'll try it tomorrow at a bank in Brussels. ;-)
You can script this stuff out in SQL Compare or SQL Data Compare, but I would use Redgate SQL Source Control. This allows you to link your dev DB in SSMS to your VCS or just a plain old directory on your filesystem ("working folder") and to keep it up to date.
However, it won't give you the PRINT statements.
For deployment, if you already own SQL Toolbelt, why don't you use DLM Automation to handle deployments in the recommended and supported fashion? Unless I'm mistaken the upgrade scrpits it generates will have your PRINT statements. / comments
You can script this stuff out in SQL Compare or SQL Data Compare, but I would use Redgate SQL Source Control. This allows you to link your dev DB in SSMS to your VCS or just a plain old directory o...
Thanks @Xanthe ! :-) / comments
Thanks @Xanthe ! :-)
Hi @Xanthe , please can I bump this one up again? (Apologies if you have already sent a 2018 logo and I missed it.)
I'd like to include the Friend of Redgate logo on my intro slide for my precon and my talk at SQL Bits. I don't want to use the 2017 logo - I'd sooner leave it out completely.
Will the logo be ready before SQL Bits? / comments
Hi @Xanthe , please can I bump this one up again? (Apologies if you have already sent a 2018 logo and I missed it.)
I'd like to include the Friend of Redgate logo on my intro slide for my precon an...
Sorry, I've not come across the log in issue before. I can't imagine it's intended that you cannot activate on machines without internet. Hopefully someone from Redgate can advise. / comments
Sorry, I've not come across the log in issue before. I can't imagine it's intended that you cannot activate on machines without internet. Hopefully someone from Redgate can advise.
https://www.red-gate.com/webactivation/activate / comments
https://www.red-gate.com/webactivation/activate
Also, Schema Compare is your friend. And the more progress you can make on the human stuff above, the easier that merge will be. / comments
Also, Schema Compare is your friend. And the more progress you can make on the human stuff above, the easier that merge will be.
This is all a question about source control branching. You should manage all the source code for all the different branches in source control.
There are of course plenty of different branching strategies with different pros and cons and plenty of people who feel strongly about one way or the other being the best and I don't fancy getting drawn into one of those debates. Ideally, however, your branching strategy should match your reality.
I wrote a bit more detail on that point here: http://workingwithdevs.com/branching-reality/
Of course, that approach will have limitations based on the tooling you choose. Git, for example, is far better able to cope with complicated branching strategies than TFSVC or SVN, but its also a bit of a learning curve and complicated branching strategies can get pretty confusing pretty quickly. It's not a perfect science despite what you may read.
However, once you have fixed the source control branching issue you should be able to deploy your code based on the source code, rather than trying to sift through a bunch of work in progress and copy specific changes from one database to another.
I wrote about one POC creating an Oracle database deployment pipeline based on source control here: http://workingwithdevs.com/continuous-delivery-oracle-databases-bamboo-redgate-1/ / comments
This is all a question about source control branching. You should manage all the source code for all the different branches in source control.
There are of course plenty of different branching stra...
Worth clarifying if it is possible to move to a Git repo in TFS? (TFS supports both TFSVC and Git repos now.) If TFSVC then you will need to limit the number of branches quite tightly for plain technical/complexity/tooling reasons.
So the advice here is to simplify your branching strategy but the necessary consequence is that you should simplify your reality to match. If your reality and your branches don't match the slipper won't fit, people will break the rules and it will be enormously painful.
So how do you do that? The simple old truths:
- Use source control and ensure it is the sole source of truth.
- Ensure all teams (Dev/DBA/test etc) are aligned.
- Limit work in progress.
- Release small batches regularly.
- Minimise the amount of concurrent epics that different teams are working on against the same codebase.
Note these are mostly human/project management changes, not technical ones. Unfortunately that will probably mean you need to push back on project managers etc, which is often difficult. / comments
Worth clarifying if it is possible to move to a Git repo in TFS? (TFS supports both TFSVC and Git repos now.) If TFSVC then you will need to limit the number of branches quite tightly for plain tec...