Comments
Sort by recent activity
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...
There was talk of doing clever grouping in the UI if the schemas matched exactly but I don't think it ever got implemented. / comments
There was talk of doing clever grouping in the UI if the schemas matched exactly but I don't think it ever got implemented.
I wouldn't disagree. :-) / comments
I wouldn't disagree. :-)
Well yes - I would expect them to be the same too - but SQL Compare is throwing a wobbly.
It's just worth being aware that the post-deploy schema check that SQL Compare is performing (and finding differences) is not with the NuGet, it's with the source directory in the DlmDatabaseRelease. I would take a look there to see if it finds something unexpected.
That may reveal in interesting clue and it may also help us to work out whether the problem is running SQL Compare or the creation of the DlmDatabaseRelease. / comments
Well yes - I would expect them to be the same too - but SQL Compare is throwing a wobbly.
It's just worth being aware that the post-deploy schema check that SQL Compare is performing (and finding d...
It is comparing the target DB to the source directory in the DlmDatabaseRelease object, not the original NuGet package.
Try doing that diff and see what shows up. / comments
It is comparing the target DB to the source directory in the DlmDatabaseRelease object, not the original NuGet package.
Try doing that diff and see what shows up.
Well done Tim. Keep it up. :-) / comments
Well done Tim. Keep it up. :-)
1. Install a Bamboo agent somewhere that can talk to the target DB. You might need multiple agents to get to all your target DBs.
2. Install Redgate DLM Automation on the target agents.
3. Your deployment steps will: Copy Nuget to target agent, run DLM Automation to deploy NuGet to target DB.
Let me know if you'd like to schedule a call to discuss in more detail.
Alternatively this is all covered on a DLM Workshop we are running later this month (EU timezone): http://dlmconsultants.com/dlm-workshops/#schedule
(On day 2 we'll cover the DLM Automation build/test functionality and we'll automate it with TeamCity. On day 3 we'll look at SQL Server Release Management using Octo Deploy. However, the principles of both days will apply to Bamboo too.) / comments
1. Install a Bamboo agent somewhere that can talk to the target DB. You might need multiple agents to get to all your target DBs.
2. Install Redgate DLM Automation on the target agents.
3. Your dep...
I think this conversation moving to a place not best suited to a Redgate forum thread. If you'd like to discuss a training or consulting engagement please can you email us. You can find the email address on our website:
dlmconsultants.com
However, to answer the technical question:
The question is can you talk to SQL Server from server 1. If you can connect to it via SSMS/SQL Compare etc then you can run all the DLM Automation build and deployment processes from that machine and do not need to install anything on target server.
However, if server1 cannot talk to target server you will need to install the TeamCity/Bamboo/Octopus agent somewhere that can talk to target server. Installing it actually on target server is an option but any server that has access to target server should be sufficient.
(And install DLM Automation on whatever machine you install the agent on.) / comments
I think this conversation moving to a place not best suited to a Redgate forum thread. If you'd like to discuss a training or consulting engagement please can you email us. You can find the email a...