User profile for AlexYates

Sprocs are only compiled at run time so dependency issues aren't uncovered simply by building/deploying the DB. / comments

Sprocs are only compiled at run time so dependency issues aren't uncovered simply by building/deploying the DB.

0 votes

In this scenario your database will not change simply by switching branches. The changes might appear as a conflict in the get latest tab? If not try using SQL Compare after you switch branches to force your local dev DB to sync up with the appropriate branch. If you try that and you still get issues my guess is it's a bug - but try it first. In general my advice is that wherever possible you to maintain a separate database for each branch. If branching is something you do regularly this will force you to get better at provisioning, which will have many nice consequences. / comments

In this scenario your database will not change simply by switching branches. The changes might appear as a conflict in the get latest tab? If not try using SQL Compare after you switch branches to ...

0 votes

What VCS are you using? Git? TFVC? etc. / comments

What VCS are you using? Git? TFVC? etc.

0 votes

Yes - that's a better idea. Do what David said. / comments

Yes - that's a better idea.Do what David said.

0 votes

Nope - but you could write a tSQLt test for it and run it as part of your build/CI processes. / comments

Nope - but you could write a tSQLt test for it and run it as part of your build/CI processes.

0 votes

Generally you want to install it on a separate machine that can talk to the SQL Server. You don't want to let DLM Automation hog the prod SQL Servers CPU and memory. Also, you can potentially just configure one deployment machine for multiple targets. Might help with all the firewall-foo. / comments

Generally you want to install it on a separate machine that can talk to the SQL Server.You don't want to let DLM Automation hog the prod SQL Servers CPU and memory. Also, you can potentially just c...

0 votes

The release isn't just the update.sql file. It's a collection of objects including a copy of the source and target states, a diff report and an xml report of the warnings. These other objects are used for various purposes, such as drift detection and reporting for approval processes. Drop the "\update.sql" from the end and it will probably start working. / comments

The release isn't just the update.sql file. It's a collection of objects including a copy of the source and target states, a diff report and an xml report of the warnings.These other objects are us...

0 votes

Sorry for the delay. I've been very busy and on vacation. Catching up on emails etc now. Firstly, following the release of SQL Change Automation in the last few weeks, you should now use this link instead: https://documentation.red-gate.com/sca3/reference/powershell-cmdlets Open disclosure: I've not tested this, but I expect something like the following may work. With 100+ database you probably want to use a list and a for each loop to save all your target databases but I'll let you google the syntax for that: #Defining variables $nuget = C:\path\to\your.nupkg $target1 = New-DatabaseConnection -ServerInstance SERVER01 -Database yourdb | test-DatabaseConnection # This uses WinAuth $target2 = New-DatabaseConnection -ServerInstance SERVER02 -Database yourotherdb -Username user -password P4ssword1!! | test-DatabaseConnection # This uses SQL Auth $releasePath = C:\some\file\share\$OctopusParameters["Octopus.Environment.Name"]\$OctopusParameters["Octopus.Project.Id"]\$OctopusParameters["Octopus.Release.Number"] #Creating release artifacts $release = New-ReleaseArtifact -Source $nuget -Target $target1 # Alternatively, try this to validate that all targets are in same start state. It will take more time to run but alerts you for drift earlier # $release = New-ReleaseArtifact -Source $nuget -Target @($target1, $target2) Export-DatabaseReleaseArtifact $release -path $releasePath #You might like to split this script into two at this point, allowing you to insert an Octopus manual intervention step in between to review the release artifacts. #You might also like to try a dry run deploy to one environment before rolling out to the rest. #Deploying the release Use-DatabaseReleaseArtifact $release -DeployTo $target1 Use-DatabaseReleaseArtifact $release -DeployTo $target2 For reference, several years ago I worked wth the folks at Skyscanner and they employed a strategy very similar to this one. Marketing video for non-techy managers: [image] https://www.youtube.com/watch?v=sNsPnCv7hHo Technical lightning talk for engineers: [image] https://www.youtube.com/watch?v=91n1mkyrSp8 / comments

Sorry for the delay. I've been very busy and on vacation. Catching up on emails etc now. Firstly, following the release of SQL Change Automation in the last few weeks, you should now use this link ...

0 votes

Ah yes, That's also a good solution - and aligns better with Octopus paradigms. It just means you have a lot more clicking to do in the Octo config - but your way will get you more of the Octopus good-ness so its probably the more natural solution. Good luck! / comments

Ah yes,That's also a good solution - and aligns better with Octopus paradigms. It just means you have a lot more clicking to do in the Octo config - but your way will get you more of the Octopus go...

0 votes

No probs. Good luck. Reach out if you want some help. :-) / comments

No probs. Good luck. Reach out if you want some help. :-)

0 votes

How can we help you today?

AlexYates

Comments