Managing Multiple Install Instances

Monday 25 August 2008 3:43:02 pm - 2 replies

2 replies

Author	Message
Gaetano Giunta	Tuesday 26 August 2008 1:00:48 pm Using svn for syncing DEV stuff to PROD is quite common procedure. You can find a nice article about that in the ez.no website dev section. You just have to decide how to lay out your svn (whether to include the full ez source or only the custom code, how to deal with the ini files that differ between dev and prod, the naming convention for the tagged releases that will hit prod after the first version etc...) and whether to use svn merge, svn switch or plain ftp/rsync for deployment on the prod server. For "things" that are stored inside the db, you can use eZ packages for moving classes, content objects or design. Unfortunately it is not a bulletproof solution, and it cannot export everything. For the likes of roles/permissions, workflows, rss exports etc, the best thing is to try to set them up as correctly as possible before doing the first duplication of the db, and then apply the changes that happen after that in the admin interface of both sites at the same time... Principal Consultant International Business Member of the Community Project Board
Russell Michell	Tuesday 26 August 2008 5:45:40 pm Thanks for your reply Gaetano, I re-read my original post, your reply and re-read that SVN article - but I now feel as though using SVN as the tool for this may be overkill because the only point of difference between each instance is only ever going to be content (text, images, uploaded files). So when I make changes to DEV, it is no problem to wholesale copy them to the document root where PROD is located. So if the only difference is likely to be in website content, it seems all I need to do is ensure these are left untouched in PROD when a data transfer from DEV to PROD is made. This is why I was asking after the location of an up-to-date ez DB schema and table description so I know which tables to omit in the import. Thanks for your reply anyway, it has made me think a little more about it :-) Cheers, Russ Russell Michell, Wellington, New Zealand. We're building! http://www.theruss.com/blog/ I'm on Twitter: http://twitter.com/therussdotcom Believe nothing, consider everything.

Author

Message

Tuesday 26 August 2008 1:00:48 pm

Using svn for syncing DEV stuff to PROD is quite common procedure. You can find a nice article about that in the ez.no website dev section. You just have to decide how to lay out your svn (whether to include the full ez source or only the custom code, how to deal with the ini files that differ between dev and prod, the naming convention for the tagged releases that will hit prod after the first version etc...) and whether to use svn merge, svn switch or plain ftp/rsync for deployment on the prod server.

For "things" that are stored inside the db, you can use eZ packages for moving classes, content objects or design. Unfortunately it is not a bulletproof solution, and it cannot export everything. For the likes of roles/permissions, workflows, rss exports etc, the best thing is to try to set them up as correctly as possible before doing the first duplication of the db, and then apply the changes that happen after that in the admin interface of both sites at the same time...

Principal Consultant International Business
Member of the Community Project Board

Russell Michell

Tuesday 26 August 2008 5:45:40 pm

Thanks for your reply Gaetano,

I re-read my original post, your reply and re-read that SVN article - but I now feel as though using SVN as the tool for this may be overkill because the only point of difference between each instance is only ever going to be content (text, images, uploaded files).

So when I make changes to DEV, it is no problem to wholesale copy them to the document root where PROD is located.

So if the only difference is likely to be in website content, it seems all I need to do is ensure these are left untouched in PROD when a data transfer from DEV to PROD is made. This is why I was asking after the location of an up-to-date ez DB schema and table description so I know which tables to omit in the import.

Thanks for your reply anyway, it has made me think a little more about it :-)

Cheers,
Russ

Russell Michell, Wellington, New Zealand.
We're building! http://www.theruss.com/blog/
I'm on Twitter: http://twitter.com/therussdotcom

Believe nothing, consider everything.

You must be logged in to post messages in this topic!