sfSyncContentPlugin - 1.0.0
A Symfony sync command for content (databases, uploads, etc)
You are currently browsing
the website for symfony 1
Symfony makes it easy to sync code between your development, staging and production servers. But what about content? Deploying content to other servers typically does not happen on the same schedule as the deployment of code. And Symfony's rsync support doesn't address the issue of copying databases. So if you're like me, you're sick and tired of copying database dumps and data files around during the early stages of deploying a site. sfSyncContentPlugin to the rescue!
symfony project:deploy syncs your code... but what about your content? This plugin adds project:sync-content, a task that can sync both your database and any folders you designate as data folders. Sync content either to or from any remote host and environment defined in your properties.ini/databases.yml/etc.
sfSyncContentPlugin is frequently used as part of the Apostrophe Content Management System as a way of pulling down content from production servers to staging and development servers and vice versa. You do not have to use our CMS to use sfSyncContentPlugin.
This plugin is not ORM-specific (you can use it with Doctrine or Propel), but it is MySQL-specific, and it only syncs your default database (most projects have only one). This plugin also requires rsync and a Unix environment on both ends (MacOS X is fine).
|Alex Gilbert||lead||moc.evaknup <<ta>> xela|
|Tom Boutell||lead||moc.evaknup <<ta>> mot|
Copyright (c) 2008, 2009 P'unk Avenue, LLC
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Symfony makes it easy to sync code between your development, staging and production servers. But what about content? Deploying content to other servers typically does not happen on the same schedule as the deployment of code. And Symfony's rsync support doesn't address the issue of copying databases, nor is it a good fit for data folders since they are usually not copied at the same time or in the same direction as code folders.
Why would you sync data? Here at P'unk Avenue we sync data in at least four situations:
Early in development, to push content up from a developer's local copy of a site to the staging site so coworkers and clients can see it.
./symfony project:sync-content frontend dev to staging@staging
Later in development, to pull content down from the staging server to reproduce bugs on a developer's computer.
./symfony project:sync-content frontend dev from staging@staging
At deployment time, to pull content from the staging server to the production server (this command would be run on the production server).
./symfony project:sync-content frontend prod from staging@staging
After deployment, to pull content back down from the production server to staging servers and development workstations in order to reproduce bugs and validate new features against real content without disturbing the production site.
./symfony project:sync-content frontend dev from prod@production
sfSyncContentPlugin can be used by itself and is also frequently used in conjunction with our Content Management System(http://www.apostrophenow.com/). The philosophy of Apostrophe is that editing should be done "in context" whenever possible.
Your project must use MySQL. This is because the code relies heavily on the mysqldump and mysql commands.
Your hosts must have the mysqldump and mysql commands in the PATH.
If your system has those commands, but under other names (like mysqldump5 and mysql5), you must add symbolic links or aliases so that they can be found under their usual names.
Both the source and the destination should be running some flavor of Unix (MacOS X is fine, but watch out for mysql and mysqldump not being in the command line path or having alternate names, you may have to fix that; Linux, of course, works great).
With this plugin installed, you can synchronize your local database with the remote database on the staging server with the following command:
symfony project:sync-content frontend dev from prod@staging
This downloads the database FROM the staging server, using the "prod" environment settings, and writes its contents to the database associated with the local Symfony project using the "dev" environment settings. We accept no responsibility for the consequences of failure to understand the words "FROM" and "TO" or use the correct environment settings.
You can also move your data in the opposite direction:
symfony project:sync-content frontend dev to prod@staging
This copies the database from the local project (using dev settings) TO the staging site (using prod settings).
Specifying a particular database connection is no longer supported as this was never much tested here. However, we soon intend to add support for automatically transferring all of the databases rather than just the default one.
You can also copy to and from production servers, etc., etc.- if it's listed in config/properties.ini, you can sync content with it:
symfony project:sync-content frontend dev to prod@production
You can also specify files and directories to be copied over via rsync at the same time. Here's a snippet of our apps/frontend/config/app.yml:
all: sfSyncContent: # The database is content, of course, but what else? content: # Almost always * "web/uploads" # If you use sfLucenePlugin * "data/index" # If you use P'unk Avenue stuff * "data/pk_writable"
This task will ask for your ssh password once to transfer the database (a big improvement over earlier versions of the plugin), and once for each entry in the content: section of your app.yml file. That's not a bug. However, you can make it go away by following (and understanding) this HOWTO:
Obviously this is a security risk in the event the laptop you are syncing from should be stolen. You must IMMEDIATELY remove the entry for your machine from authorized_keys on the remote server in that situation.
Also, the code has been refactored to reuse the mysql-load and mysql-dump tasks locally as well as remotely, removing redundant code and the potential for problems like the bug fix mentioned above.
Version 0.9 has been rewritten to use sfDatabaseManager and remote dumping and loading tasks to eliminate extra ssh connections and allow the use of any databases.yml file without modification (however there is still no support for multiple databases or non-MySQL databases). Version 0.9 removes the largely untested halfhearted support for specifying a particular connection. If we're going to support multiple connections it should probably be by syncing all of them or just the default based on a parameter.
Version 0.3 (not yet packaged) is the first Symfony 1.2, Doctrine-and-Propel version, with a shiny new name.
Version 0.2 changes the syntax a bit to require an environment name for the remote Symfony site as well. This adds flexibility and helps to prevent the accidental use of inappropriate database settings.
"Why do I have to specify an application?" This is a feature. The content settings live in app.yml. Pass frontend or whatever your main application is.
"Why do I have to specify an environment?" This one is a feature too: different sections of app.yml can come into play depending on the environment. Even more important, databases.yml can also have separate dev and prod environment sections accessing entirely different databases, one reason why I now require that you explicitly specify the environment for the remote site as well.
This is a power tool, for grownups only. We accept NO responsibility for the consequences of using this tool. If you are not backing up your databases, and you fail to understand the meaning of "from" or "to," don't come crying to us. Seriously.
That said: it's very useful. Enjoy. (:
P'unk Avenue LLC, www.punkave.com
Released under the MIT license. See the LICENSE file for details.
Tom Boutell, firstname.lastname@example.org