Multi-Envrionmnents + Deploying + Database Migrating

would like to know more about syncing databases too. This is where I get stuck also.

We’ve been copying database dumps directly and then a search and replace to update the directory paths. We keep db names, user, password the same in all environments so we do not need to change those.

But yes, there must be an easier way that we don’t know.

This is an issue all EE devs face. I’ll share how I work. Hope it helps.

First and most important is to bootstrap your config.php and database.php files to work in multiple environments. There are many ways to achieve this but the end result is that you have a single file for all configurable settings for each environment. You can then deploy the project to any desired environment using whatever source control method you prefer. I have my own bootstrap system which I’ve not released, but NSM have a public one: http://ee-garage.com/nsm-config-bootstrap

Next up is to avoid the use of hard-coded absolute paths anywhere other than your config files. For example, an image source should always be “/path/to/image.jpg” rather than “http://mydomain.com/path/to/image.jpg”. This is especially important for of Upload location urls. Keep things relative and you can move between environments with ease.

Now let’s consider the database itself. Your life will be much easier get the DB schema ironed out early in the project. Identify and set up all member groups, member fields, channels , field groups, category groups, statuses etc at an early stage. I’d also include in this any channel entries that have an entry_id or url_title hard-coded into a template. Your dev team can then each take a copy of the database and complete their work. It shouldn’t matter if they all have the same data provided they all have the same schema.

If the schema does need to change, or a data update is useful, devs can simply grab a new dump from the master database. There shouldn’t ever be a need to ‘sync’ as such.

There is only one table that causes a problem with this: exp_upload_prefs It’s about the only instance of server paths that cannot be delegated to your config bootstrap. The way I get around it is simply set them up at the start of a project and then never update that table between environments.

Some get around this issue by having their dev filesystems use the same structure as production, but I find this unworkable. I’ve yet to work on a project where exp_upload_prefs needs updating more than once or twice during development, so it’s only a minor annoyance.

Great feedback, thanks.

Yeah, I currently use the config_bootsrap file and it really is a life saver.

Currently my process for deployment (when also updating DB) is:

• Commit all changes to git repo.
• Push new changes to git repo.
• Dump Local DB.
• Deploy code via Capistrano gem.
• Merge upload directories
• Load .sql file into remote DB.
• Use Deeploy Helper module to switch all path related settings (channel urls/paths, upload url/paths, other misc. settings)

That process works very well, but on some projects, the client wants a staging server and a production server, and I find myself performing these migration pretty frequently.

I’m currently in the process of writing a capistrano recipe that will try and eliminate some of this process. The major things I want to help auto mate are:

DB Migrations

cap migration:db:pull cap migration:db:push

Migrating shared upload directories

cap migration:files:pull cap migration:files:push

I’m also trying to build in some versioning, so you can do things like cap migration:db:rollback , if something fails.

Hopefully I’ll have a working version up on github sometime next week.

Did you ever have any luck creating the DB capistrano recipes? I’m just getting into this more because the deployment process has been such a headache. Would love to know how you’re resolving it….

I never ended up finishing the capistrano recipe, and it got to the point where I scraped it in favor of trying to build an Add-on to handle much of this. Only problem is I havn’t had the time to build this add-on.

As was previously mentioned, this is a pretty common problem most EE devs run into eventually, and I would love to hear more about how each developer manages it themselves. How are you doing it now and any other general thoughts on the workflow that would be ideal?