Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>My process is usually managed around a source control repository (SVN in my case), which makes things much easier (or possible, really...). The idea is to keep everything possible in the repo and use SVN updates and tags to publish changes. </p> <p><strong>local.xml</strong>: I move this file in SVN to <code>local.xml.dist</code> and ignore the actual <code>local.xml</code> file in the repo. This lets you use different database credentials and hosts on your installations without polluting the codebase.</p> <p><strong>other ignores</strong>: Check out <a href="https://stackoverflow.com/questions/2058617/magento-subversion-svn-getting-a-development-environment-started/2064637#2064637">this question</a> for more files that should be ignored in the database. Basically, anything unique to the environment should be kept out of version control and handled on the actual host. Your <code>.htaccess</code> files will be relevant here.</p> <p><strong>host setup</strong>: My staging environment and dev environments are set to run off of /trunk from the repository. Development occurs here, and can be pushed to stage periodically (or on demand) via <code>svn up</code> to show new features to the client and do UAT. The production environment needs some protection from the Wild West of trunk, though, so that environment runs off of tags. Whenever a feature set is ready to go out, I create a new tag from trunk and do an <code>svn switch</code> to move to the new code set. Doing things this way also gives me an easy undo for production (switch back to the last tag). Thus I have removed all manual file pushes from my life, which is good.</p> <p>An even better system (which I've had no need for yet) would be to use <code>svn export</code> to create a complete copy of the code tree on the production system, and use <code>ln</code> to switch between them. Something like this:</p> <pre><code>&gt; cd /home/apacheuser &gt; ls -l www -&gt; /home/apacheuser/tag_1.0.1 tag_1.0.1 &gt; svn export /url/for/repo/tags/1.0.2 tag_1.0.2 ... svn exports here ... &gt; rm www; ln -s /home/apacheuser/tag_1.0.2 www </code></pre> <p>That way, version changes are instantaneous.</p> <p><strong>db sync back from production</strong>: To allow me to work on production-ish data, I have a cron-job set up to dump the production database and import it into staging. While this is happening, the script will remove sensitive customer data (and change customer email addresses so that all emails go to me). It will also change credit card gateway settings to a test gateway and change the <code>base_url</code> parameters so that the staging site URLs work properly.</p> <p><strong>new development</strong>: You may notice here that different environments run off of roughly the same codebase (minus any new changes), which may seem troublesome to you from what you've noted about database changes etc.</p> <p>The only way to manage this complexity (and the right way, at the same time!) is to make sure that the code itself keeps track of necessary changes to the environment. Magento supports automatic module version upgrades, including database scripts, which you should use to make schema changes, etc. This means that, as you deploy new code to staging/production (or as you get it from another developer in your dev environment), all database patches are applied automatically.</p> <p>This also means that you need to write new functionality to be as non-destructive as possible. Magento themes, disabled modules and such can be used to make this a reality. For example, when creating a new theme for the site, make sure not to modify any of the core behavior, and keep all new assets in a theme that will be inert on production until deployed.</p> <p><strong>more developers</strong>: This setup is based around a relatively small number of developers on a project. There is an implicit assumption that, when you want to tag a new release, you can get trunk into a working state to do so. With more developers, this will be the case less and less, so a more complex repo setup is necessary. If I run into that, my plan is to move over to using git instead of SVN and to use feature branches for new development.</p> <hr> <p>Let me know if any of that was unclear. Hope that helps!</p> <p>Thanks, Joe</p>
    singulars
    1. This table or related slice is empty.
    1. POMagento staging and production
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USJoseph Mastey
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO@Joe - Just awesome answer. However, I would like to know about the DB Sync Cron Job details, if you don't mind to share. It's very much interesting to know how this test gateway & the removal of sensitive data takes place, along with change of primary Email ID, and some more.
      singulars
      1. PO
      1. USKnowledge Craving
    2. CO@Knowledge Carving this is actually the easiest part and involves calling mysql queries from command line (or from prepared php file) as most of config values are in core_config_data and are just updatable or deletable by path. I'm replacing all client e-mails to be my own youremail+clientid@yourdomain.com so no accidental e-mails are sent out to clients from testsites. Replicating a mysql database to dev instance is just exporting the dump and excluding log files and recreating dev db with exported dump.
      singulars
      1. PO
      1. USAnton S
    3. COWhat he said :)
      singulars
      1. PO
      1. USJoseph Mastey
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload