We are a team working with Magento 1.7. In order to manage deployment between different developer working with the same database of Magento. We suggest to use binary logs.

Each developer will possess his own Magento environment in localhost. To deploy into server, we are using Git for deploying files, and for the database, each developer has Mysql Workbench to generate a binary log of his database, each binary log will be deploying into server and Git will synchronise one database into server.

We prefer avoiding working in the same database. What do you think about this solution? Any suggestions please.

  • 1
    what do you mean by Binary logs? Jun 26, 2013 at 11:22
  • @FlorinelChis binary logs are like an event log that allow point-in-time recovery. They're instrumental in replication set ups. dev.mysql.com/doc/refman/5.0/en/binary-log.html
    – philwinkle
    Jun 26, 2013 at 13:59
  • @philwinkle great, now hoes does that make sense looking at what he is trying to do... I thought he meant something else by binary logs, something specific to his stuff... Jun 26, 2013 at 14:11

3 Answers 3


A novel but terrible idea :-). Will blow up miserably due to foreign key collisions.

Better to use proper setup scripts for non-conflicting changes. For settings and entity fixtures use a common setup module or two and enforce consistency via git workflow.

  • Thank you for your reply. Please could you give me more details.
    – Floria
    Jun 26, 2013 at 11:47
  • Here's a tutorial on setup scripts and the config & resources which declare & run them: magentocommerce.com/knowledge-base/entry/…
    – benmarks
    Jun 26, 2013 at 11:53
  • Thank you very much Benmarks. Do you think that this issue is the best way to managinh deployement in Magento ? Best regards.
    – Floria
    Jun 26, 2013 at 12:43

I fully agree with @benmarks, and this answer is supplemental to his correct answer.

If you're looking to batch updates, you can try one of the upgrade batch extensions that have cropped up from ECG or from Fabrizio Branca / AOE. This, like your MySQL binary log idea, is a way of aggregating updates into discrete batches that can be run at-will.

I've never tried these plugins, though in the past (EE1.10 -> EE1.11) I desperately wish that I had them.

Fabrizio Branca's Upgrade Replay:


Magento's ECG derivative of that same codebase:



Ben is 100% correct here (as usual).

When developing, use deployment scripts. This way, schema changes are propagated out to your developers (and to your environments) in a relatively seamless mannor.

An additional word of advice... if you ever find yourself, as a developer, clicking "create attribute" ... stop, and do it via an attribute installer script. Migration of attributes in Magento is non-existent outside of adding it to your install scripts.

Down the line, when you've added 20 custom attributes you're going to be wishing you had done the work up front.

Create them via admin for testing them all you want but delete them and recreate them via install script for your team and sanity.

  • Thank you very much guys for your advises. But as a novice developer, could you please give some resources in creating deployment scripts. Thank you very much.
    – Floria
    Jun 26, 2013 at 15:02
  • For module setup scripts (say you create a module that has custom database tables), Ben's link is a great resource.
    – CVEEP
    Jun 26, 2013 at 17:27
  • For attribute setup scripts (the same thing as above really, you're just telling the script to setup attributes instead), this is a really good place to start.
    – CVEEP
    Jun 26, 2013 at 17:28
  • My second link for attribute setup didn't come through the parser correctly. This one should work better.
    – CVEEP
    Jun 27, 2013 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.