I'm a little surprised that making SQL changes is not seen as a popular choice.
Let me describe the process I'm trying to create...
I have roughly 50 x Win2012R2 servers which need to get updated regularly (once a week – with the same update).
Each server has an instance of SQL2014 Express running a local DB
The update consists of:
A folder of around 300 executables (our bin folder)
A folder of around 100 .bat files (our utils folder)
Depending on the type of release, we may also need to make DB changes. These are usually simple – e.g new table, column etc.
To perform the update, we currently have a tool which will stop a bunch of services, pull down the bin and utils folders over SFTP (replacing the old ones), run the DB updates (if required) and then restart the services.
This works fine but it still needs to be done on a host by host basis (a human needs to log into each host and run this GUI based upgrader tool)
I'm looking for DSC to do the same job but in a more scalable fashion.
For this to work, I'll need to make SQL changes as part of the DSC "pull".
I had envisaged doing this by pulling down a text file and scripting the execution of the SQL commands inside this file.
You say that you don't think that DSC should be used this way – can you elaborate a little to explain why you wouldn't take this approach?
Is there a better way to achieve what I'm looking for?
The topic ‘SQL Changes (Tables/SP/Jobs) Deployment using DSC’ is closed to new replies.