We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 20466
    • 2 Posts
    For larger sites that need to maintain a staging environment on a single server and a production environment on load-balanced servers, what are the recommended best practices for implementing MODx?

      • 32319
      • 129 Posts
      Quote from: MrT at Jun 12, 2007, 07:01 PM

      For larger sites that need to maintain a staging environment on a single server and a production environment on load-balanced servers, what are the recommended best practices for implementing MODx?

      The best process I have found for running a stage to live process is this:

      1. Back up STAGE assets folder.
      2. Upload STAGE assets folder to LIVE server under the name assets_new.
      3. Backup STAGE and LIVE database.
      4. Take LIVE “offline”.
      5. Open the config.php file for LIVE and change the database name, username and password to the current STAGE database then save.
      6. Change the name of the LIVE assets folder to assets_MMDDYY (Month Day Year of outgoing database).
      7. Change the name of the LIVE assets_new folder to assets.
      8. Verify that permissions are properly set for assets directories.
      9. Update LIVE sites file manager configuration paths.
      10. If your using the Google Analytics plugin update it with your user key.
      11. Check that LIVE site is operational.
      12. Set LIVE site to “Online”

      This process usually means a downtime of the live site for less than one minute. To make it even faster, you can update google analytics and the file manager paths after the site is back online.

      To re-setup STAGE I create a new database named under following the format [tt]wwwMMDDYY[/tt] (Month Day Year) and load the backed up database into the new database. This also gives me the benefit of having a fairly simple roll back to a prior database and assets pack if there turns out to be a problem down the road. Every now and then I archive the old assets and databases and delete them from the server.
        "Regret for the things we did can be tempered by time; it is regret for the things we did not do that is inconsolable."
        -- Sydney Harris
        • 20466
        • 2 Posts
        I like the process you’ve built. Are you currently using this to replicate a single staging server to multiple front-end web servers with a single backend db (or db cluster)?

          • 32319
          • 129 Posts
          Quote from: MrT at Jun 13, 2007, 01:43 AM

          I like the process you’ve built. Are you currently using this to replicate a single staging server to multiple front-end web servers with a single backend db (or db cluster)?

          No, it is just a one to one transfer but I am sure you could modify it slightly to suite your needs depending on your exact configuration. I am also interested in hearing how others have approached this problem. I am always looking for ways to improve my push process so let me know what kind of changes or ideas you come up with to suite your needs.
            "Regret for the things we did can be tempered by time; it is regret for the things we did not do that is inconsolable."
            -- Sydney Harris
            • 27376
            • 576 Posts
            To synchronize the db between my live and dev sites, I use Navicat (commercial). To synchronize the filesystems, I use Subversion (freeware). Most of the time this can be done without even marking the site as offline, but my site sees only around 1000 visitors.

            On large updates where I need to update both the filesystem and the db at the same time, I’ll take the live site offline. This will usually last no more than 5 minutes if all goes well. I love how MODx allows you to see your site when it’s offline if you’re logged in.

            Future versions of MODx will make it easier to sync live and dev sites as OpenGeek has stated in many threads. smiley