Development and Live Sites, Migration Strategy

what are you changing? only content or also the filebase?

dWise, I don’t know how to answer your question. My reason for bringing this topic up is that I always like to develop sites on my own domain, so that I have control over the work I produce and can wait until payment is made to launch the site and give the client control over the entire thing.

My ideal situation would be to build the site and add content on a dev server location & database, and then, when I wanted to launch, simply move the full directory to the client’s live environment, and keep the database the same? I’m just trying to streamline the process as best I can, as the development > production migration is going to be something I do very frequently (probably every project). Does this help clarify my question?

You could develop in a sub-directory as you’ve suggested. I did that once to a degree and it worked fine.

When we start new projects we build everything locally 100%. It doesn’t reside on the final domain/server until it’s signed off on and all that good business stuff. Once we’re ready it’s a matter of transferring all files and folders (and verifying folder permissions) and doing a full sql dump. It’s a pretty simple process for the initial launch migration.

Does that help?

Yes Erik, that’s very helpful, thanks.

I guess I’ve just been working on a few sites which have no really “private” information, and they are repeat clients who I trust… so I was just looking for the easiest way to set up the system… ideally to save myself the MySQL dump. In other words, I’d like to simply “turn on” the site instead of a full “migration.”

This info will absolutely be helpful for other clients. Thanks for your response.

Glad to help. 😊 I completely understand wanting the ability to flip a switch rather than a multi-step migration :p

If I can chime in with what we’ve recently started doing…

We’re using NSM Config Bootstrap so that EE knows which environment (development, staging, production) dynamically from the URL. That way we don’t have any real config file changes between various environments. The bootstrap handles it all.

http://www.ee-garage.com/nsm-config-bootstrap

Then, for the actual deployment to staging or production, we use Beanstalk. It’s version control at its heart (either Git or Subversion), but the paid plans also include a deployment tool which will let you set up different servers to deploy to. We usually only have staging and production. Once you’re ready to deploy, Beanstalk is smart and only deploys the changed portions of the site. So in this way, you can have your development and staging versions of the site miles ahead of production, and when you’re ready to send your changes to production, it’s just a few clicks to do so.

http://beanstalkapp.com/

This workflow is working really, really well for us!

Then, for the actual deployment to staging or production, we use Beanstalk. It’s version control at its heart (either Git or Subversion), but the paid plans also include a deployment tool which will let you set up different servers to deploy to. We usually only have staging and production. Once you’re ready to deploy, Beanstalk is smart and only deploys the changed portions of the site. So in this way, you can have your development and staging versions of the site miles ahead of production, and when you’re ready to send your changes to production, it’s just a few clicks to do so. http://beanstalkapp.com/ This workflow is working really, really well for us!

That’s exactly what we do. Great service! I’m playing a bit with beanstalk’s hooks now. I’m curious what you think, Jeremy.

http://erikreagan.tumblr.com/post/2362696342/ee-deployment-thoughts