4

I work for a small agency and we often have more than one developer working on a magento project. We work locally, and then commit to github after each phase of development. The problem we are having is managing the database content.

Currently, each developer takes a sql dump of their local database and pushes that to github as part of the commit. We have a system that takes the github repo and pushes that to a staging server. Part of the system grabs the sql dump file and updates the staging server db.

The problem we have is that if dev 1 has - for example - created a bunch of cms pages, and dev 2 has installed and configured some modules, merging the 2 sql files is very difficult, and we end up spending way too much time merging the two dbs.

Can anyone suggest a better workflow process to handle this?

| improve this question | |
4

At our firm, we only have the staging database; the developers periodically dump and restore the staging database to their local environment. If they have to create/edit any CMS pages, upload media, etc, these are done on the staging server as part of their commit. If they create CMS/media locally, they'll have to do it again on the staging server.

Committing an SQL dump file seems to me the wrong way to go about it. In version control systems, you should really be versioning code only, not data. At our firm, we also version the entire Magento code base and every thing except the var and media directories (including all skin images). This seems overkill to me, but the developers prefer to checkout the repository, create their app/etc/local.xml and have a fully working development environment. For personal projects I only version the code that I write and modman.

| improve this answer | |
  • Thank you, useful answer. But I do not get a thing: when you need to put changes in production/live, how do you bring changes made in the staging database to production? Do you replicate all changes manually? – Andrea Sep 25 '16 at 9:46
1

Another way would be for developers to share the database.
Imagine 2 developers working on a site, They have a common mySql Server and each use apache running on their Local machine.

For Example, If the base url is set to www.dev-example.com
Dev-1 and Dev-2 create a host entry for it to redirect to 127.0.0.1, And set up magento on their servers
Both magento instances point to the same database and Dev-1 can see changes made by Dev-2, making it easier to collaborate

| improve this answer | |
  • This is the approach I think we're leaning toward. An issue raised amongst the team was "what if one developer does something (installs a module for example) that breaks the db". Then all of the devs are stuck. Any suggestions? Our though was that we could set a cron to take a back up of the staging db every 15 mins or so, and have that as a resource to roll back to. The dev who "broke" the db could work locally until they've resolved the issue, and then migrate changes back to the staging db. – matt May 5 '15 at 16:24
  • you could use a separate back up db that gets updated every day or may be at closer intervals like every 6 hours, I think a full db copy every 15 minutes may be a waste of space or resources – NathanielR May 7 '15 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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