Managing releases for the database

[Voltramas]

Question - it has been awhile since I have used Intersect. One issue I found was with version control on the server database.

 

Since the editor allows changes to the live database, what are common ways of controlling which changes make it to your production database? Can we just put the client in source control and manage that way? Do you test in your dev env, then once quality is there, replace the live database with your dev database?

 

Is there a database update process that can be used?

 

Mainly asking a question to see what people have done, if they do it all. I hope this is the right forum. 

 

Thanks!

[jcsnider]

Correct forum for sure.

 

We don't really have any sort of change/revision tracking within the editor (and we really should!) -- hopefully that will come in the future.

 

I think the best way to do it is to have 2 servers, a low powered development server in which you edit and then a higher powered production server for players.

 

Then you have a date each week where the production server goes down for a few minutes for updates and you replace the production game database with the latest development database.

 

That keeps updates rolling out at a stable pace while also making sure no one ever has editor access to your production server.

[Voltramas]

Thanks for the quick response! That makes sense, and since all of the game data is stored in a separate database, looks like Intersect supports that workflow.

 

Agreed, some built-in revision tracking would be a cool feature! Allowing less dev oriented users to simplify their release process. It would be interesting to see how that could work, i.e. a "temp" db the editor accesses, then some way to deploy it via the editor. I guess this would exclude changes to the Client (resources, images, sounds). But could be done with some tweaks too.

 

Appreciate the input I will look into the database deploy method in the meantime.