Self supporting remote client updating?
ppat
Posts: 6
In my development env, sqlcompare is great as I just point it at my dbs and run it. I've started to get it also working with TeamCity. What about when my software is actually installed at a client site? I'd like to give my software the ability for it to upgrade itself. Let's assume I install 1.0.115 [major,minor,svn revision] at a client site. Now I finally want to release revision 233. What steps are those of you taking?
Right now I feel like I need to write my own utility to
1) At every release, run sql compare between the prior official release db and the current release, and store this migration script somewhere.
2) When my app runs it's auto upgrade, I have to write code for it to (backup first) and then download every migration script since and apply them in order.
Alternatively, for #1 above, I teach team city or a custom utility to store every single migration script that comes out of svn and I run every one of them in order.
Am I missing something? I know a lot of you just use these tools against remote live dbs that you have direct control of and you are responsible for all the updating, but in my case, think of my software like a boxed quickbooks, and I would really want each install to be able to upgrade itself on it's own. I don't want to have to license the sdk for every 10 clients and teach my app to compare itself against some public template and run some untested script.
Right now I feel like I need to write my own utility to
1) At every release, run sql compare between the prior official release db and the current release, and store this migration script somewhere.
2) When my app runs it's auto upgrade, I have to write code for it to (backup first) and then download every migration script since and apply them in order.
Alternatively, for #1 above, I teach team city or a custom utility to store every single migration script that comes out of svn and I run every one of them in order.
Am I missing something? I know a lot of you just use these tools against remote live dbs that you have direct control of and you are responsible for all the updating, but in my case, think of my software like a boxed quickbooks, and I would really want each install to be able to upgrade itself on it's own. I don't want to have to license the sdk for every 10 clients and teach my app to compare itself against some public template and run some untested script.
Comments
Thanks for contacting us and this is an interesting issue!
I don't know if this is possible in your scenario, but using the DLM Automation Suite with SQL CI/Team City for the automated build-test-package steps and SQL Release/Octopus Deploy for the automated package extraction and deployment seems to work really well for many of our customers.
If you did not want to do that then you could do what you described, the migrations you describe seem very feasible and I might add that you could package up the deployment scripts using SQL Packager then move the package to your client's machine and deploy it.
More documentation on that https://documentation.red-gate.com/disp ... +a+package
Please let me know if that helps!
Warmly,
Technical Sales Engineer
Redgate Software