PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Wed Jun 26, 2019 8:08 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Tue Sep 03, 2013 5:41 am 
Offline
Forum Newbie

Joined: Tue Sep 03, 2013 5:36 am
Posts: 1
 Hi,
I am Suresh as a web developer. In our new project, we have to revamp and existing magneto site (1.6.2.0) to the latest.The other requirements we have is to change the skin and add few more funcationalities into the upgraded version and update the database version as well.
There is one questions for which I am very curious is :
Q1: As the project is going to take couple of months for development, how do we going to merge the changes which users will be making on the live site into the new platform ?
Example : People will be buying new products, there will be few products those need to be shipped, new customers will be added, new products, orders will be created into the system.How do we going to push the new setup on production while also retaining the latest data from production in the new platform.
Q2: We cannot just import the latest DB in the new platform as the new platform will have its own changes at DB level as well. Thus importing current production DB in the new platform will override the newly added extensions and new tables.
Warm Regards,
Suresh Sharma


Top
 Profile  
 
PostPosted: Sat Nov 02, 2013 12:36 am 
Offline
DevNet Master

Joined: Wed Feb 11, 2004 4:23 pm
Posts: 4872
Location: Palm beach, Florida
Use database migrations. A good tool I use is robmorgan/phinx.

No one is allowed to change the database or edit anything in the Magento admin panel. Everything must be done through a phinx migration. If you are going to make 100 edits to a CMS page, the 1st edit should edit the DB to make it read from the filesystem, the other 99 edits are editing the file on disk. The idea is to avoid changing the database, change it as few times as possible. When you do have to change the database, do it with a script that is repeatable.

When it comes time to upgrade, you basically just play back all the migrations that change the database in the same way you originally did. Also I would have a good rollback strategy. I version my sites like this:

10-01-2013
10-14-2013
11-01-2013
live -> 10-14-2013 (this is a symlink).

When I "upgrade" I'm really just updating the symlink. Rolling back involves just pointing it back. Each datestamped folder has it's own database since bad code could hose your data. Ideally you would show your users a maintenance message before you upload the new datestamp folder, and remove it after that folder is live. This prevents orders coming in after you've copied the database, but before you update the symlink (such that they would not be present after the switch).

Also hopefully your themes only override the files that were actually changed. Its common bad practice to copy all files from "base", even when they don't change. In this case you can use your VCS like git to see if files actually changed, and if not, delete them.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: Exabot [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group