TeamCity PlugIn - is this the way to go?

Spud

Hi, apologies if this question is a little "fluffy", but resources as to exactly what the TeamCity plugin does seem to be hard to find, so here goes..

We currently have

a) A nice TeamCity build creating setup kits for our .net check-ins
b) Our database Changes in redgate SQL Source Control.
c) Database change scripts created manually using another 3rd party tool (I hear you say "boo!" ).
d) Scripts deployed automatically via our own software

So far so good, but the next step is to get SQL scripts output by our TeamCity build, by purchasing SQL Compare, and *presumably* the TeamCity plug in.

Is this what the TeamCity plugin can be used for, or does the plugin update the target database(s) as part of the build? (NB I want the output of the build to be SQL scripts / something else that we can rollout via our software)

It sounds like you cannot include migration scripts using the plugin (http://www.red-gate.com/messageboard/vi ... hp?p=60327) so is the plugin going to do what we want, or should I be using SQL Compare from the command line as part of the build.
I'm assuming the plugin doesn't do everything the command line does, but cannot find any comparisons.

I hope my ramblings make sense. Thanks in advance.

Brian Donahue

Thanks for your question. The TeamCity plugin's main purpose is to create NuGet packages for deployment using automated deployment tools like TeamCity or Deployment Manager. You don't need the add-in to turn a live database into a series of scripts; you can still use SQL Compare for that.

If this fits better into your existing CI framework, you can still use the SQL Compare command-line. The only thing you will need is a licence (automation licence) to run the command-line on a server other than the one where you normally use SQL Compare.

When the TeamCity plugin documentation refers to "migration scripts", that term specifically denotes custom scripts you use to replace the scripts that SQL Compare automatically creates. The reason why you would do this is, for instance, if you changed a column from allowing nulls to NOT NULL and you needed to insert a line to update all existing null data to prevent the schema update from failing.

Spud

Thanks for your reply Brian.
For us it looks like the command line is the way to go, even though I currently have a few outstanding issues with it.

We want the build to output scripts, and it looks like the only way to get the TC Plug in to create scripts is via the deployment manager, so we're plugging away without the TC Plug-In.