Comments
Sort by recent activity
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...
Grrr. bbcode does not seem to handle my whitespace very well. :-( / comments
Grrr. bbcode does not seem to handle my whitespace very well. :-(
This might require a longer conversation to explain the process. Feel free to start a private thread on Twitter/Linkedin etc and we can set up a quick 10 min call etc.
In brief:
What do you want to achieve?
IF (Build once, deploy immediately to test only){
As part of your build process add a step to SYNC the code to your test DB and ignore the deployment
functionality of Bamboo.
This is the simpler JFDI approach.
}
ELSE IF (Build once, deploy to multiple environments on demand at the click of a button){
Publish your NuGet package (gets created by DLM Automation, you don't need a separate NuGet install)
Use the release management functionality in Bamboo by setting your deployment steps.
These deployment steps will use either RG plugin or PowerShell to deploy your NuGet packages.
This is the more mature, configurable and scalable approach.
}
ELSE {
Please explain exactly what you want to achieve in a bit more detail.
}
I hope that helps. / comments
This might require a longer conversation to explain the process. Feel free to start a private thread on Twitter/Linkedin etc and we can set up a quick 10 min call etc.
In brief:
What do you want to...
You need to save the package that you created in your build plan as an artifact.
Then you need to create a deployment plan to deploy the package to the other environments.
I can't find a SQL Server or plug-in walk through - but I wrote this blog post (first of a 2 parter) which talks you through a similar process for Oracle databases using command lines and powershell scripts etc.
The Bamboo bits are mostly the same. http://workingwithdevs.com/continuous-delivery-oracle-databases-bamboo-redgate-1/ / comments
You need to save the package that you created in your build plan as an artifact.
Then you need to create a deployment plan to deploy the package to the other environments.
I can't find a SQL Server...
By default DLM Automation will try to create a database on localDB on the Bamboo agent (whether this is an on prem or cloud agent). https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/sql-server-2016-express-localdb
If local DB is not installed on your build agent you should provide details for your own SQL instance where DLM Automation will build the database. / comments
By default DLM Automation will try to create a database on localDB on the Bamboo agent (whether this is an on prem or cloud agent).https://docs.microsoft.com/en-us/sql/database-engine/configure-win...
I'm afraid there isn't. Not without unlinking and relinking anyway.
Can you tell me a little bit more about your custom objects? Are these for different versions of production (e.g. for different customers) or for dev/test databases? Are we talking about schema or static data differences? What sorts of objects? Tables, sprocs etc? Do you have handy naming conventions?
There are clever things you can do with filters and post deploy scripts etc. For example: https://www.red-gate.com/hub/product-learning/sql-compare/how-to-build-multiple-database-versions-from-the-same-source-using-sql-compare-filters / comments
I'm afraid there isn't. Not without unlinking and relinking anyway.
Can you tell me a little bit more about your custom objects? Are these for different versions of production (e.g. for different c...
I'm afraid not: https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/1267757-allow-me-to-specify-a-subset-of-columns-for-static / comments
I'm afraid not:https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/1267757-allow-me-to-specify-a-subset-of-columns-for-static
I'm trying to think of a good way to do this but can't think of anything better than move the static data and "not static data" into different tables.
Is there any reason why you can't do that? (Other than the fact that this sounds like a complicated data migration). / comments
I'm trying to think of a good way to do this but can't think of anything better than move the static data and "not static data" into different tables.
Is there any reason why you can't do that? (Ot...