4

I'm 95% of the way through a project just now and soon I am going to have to move EE from the 'development' folder to the 'live' folder. My questions before I do this are:

  • Can I just copy all the EE files from the 'development' folder to the 'live' folder and then change the paths specified in the docs? If so are all the login details the same?
  • Do I need to create another database or can I use the same one that is already set up?
  • Can I keep the 'development' version where it is in case I need to do anymore development?

I am fairly new to EE so any help is much appreciated.

Thanks. Stephen.

Improve this question

3 Answers 3

Reset to default
13

I'm going to address this part:

I am fairly new to EE so any help is much appreciated.

I think you'll find that many of the developers here are currently using a workflow that incorporates version control, typically Git via Github or another service.

In most cases, our workflow looks like this:

  1. We start development on a local computer, with our database and site files there. As mentioned in another response, we use FocusLab's approach to config files to keep the site portable: Providing the database variables are updated or kept the same, we should be able to move things around without impact.
  2. When client review starts, we set up a Staging subdomain on one of our servers: Something like clientname.clearbold.com. We set up a database on that server with the same name & username/password as we had in dev, so no changes to the database config are needed. This sounds like the dev site on your live server.
  3. We'll dump a copy of the database in dev into a directory in our version-controlled project directory, and push it to our git repository. We use a deployment tool (Beanstalk or DeployHQ are good options) to (S)FTP all the files to the server. You can also log into your git repo on the server and pull down the files.
  4. We then import the database on Staging, and the site's running.

Now, once we get to the point where the client is making edits, whether to Staging if we're pre-launch or on Production if we've launched, that database is now the master. Any time we do development, we log onto the server the client is using, do a database dump, and copy that down to our dev machines. We import that locally to work with the latest content/data, and we include that dump file in our git repo so that all developers can get it. If the Production site is the master, we may want to update Staging with that dump so we can demo some new features there. This is really important. For us, the database is always a one-way update. We add new fields or install new add-ons in the master database, and then copy it down to dev to start working with it.

In your case, I'd recommend:

  1. Updating your config to use the FocusLab approach, so that you can copy your files into the live site directory without changing paths. This will also enable you to copy the site locally in the future to test updates/upgrades, develop new features, etc.
  2. It's fine to keep your current "dev" (more accurately, Staging, because the client can see it) site pointing to the same database. Since I've advocated always making modifications in the master database first, there's no need to copy from Production to Staging. Just be careful if you're testing new features via your Staging site.
  3. Be sure to make backups of your db before making any changes.

Virtual Servers, whether running Plesk like MediaTemple's DV or barebones like their VE, or any of EngineHosting's offerings, etc should let you enable and log in with SSH. I highly recommend getting the hang of this. Running mysqldump and mysql import from the command line are much, much more efficient than using PHPMyAdmin. (We run Rackspace Cloud and A Small Orange servers currently.)

I actually did a video of this workflow, using git and moving database dumps around, a while back:

https://s3.amazonaws.com/clearbold-content/EE-git-screencast.mp4

Improve this answer
4
  • how do you resolve where you're making changes to the db schema in dev and the client is adding content in production?
    – Steven Grant
    Feb 7, 2013 at 14:51
  • 1
    You have two options: 1) Always make your schema changes in production. If they're new fields, and they're not referenced in template code, or new add-ons, there's no harm in this. Then just pull down a fresh copy. 2) Keep detailed notes of everything you did in dev, then manually reproduce those steps when you're ready to go live. I've advocated always making Production your master and grabbing fresh dumps of that database to work off of in dev.
    – Mark J. Reeves
    Feb 7, 2013 at 14:54
  • yeah, pretty much how we roll. Oh to have EE running on MongoDB :-)
    – Steven Grant
    Feb 7, 2013 at 15:14
  • Wow, thanks for the detailed explanation, homework for the next few weeks - try to figure out how this works! I appreciate the time you've spent explaining it to me.
    – Stephen O'Connor
    Feb 7, 2013 at 18:08
5

The FocusLab approach to this has become a de facto standard for what you're doing, especially long term:

https://github.com/focuslabllc/ee-master-config

Hope this helps.

Improve this answer
0
1

I used this tutorial and it works just perfect: http://www.creat-ee.com/tutorials/more/migrating_your_ee_site_to_live_server

Francois

Improve this answer
0

Your Answer

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

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