[wp-hackers] Deployment process (was Exporting Menus)
vid at zippykid.com
Wed Sep 1 11:16:16 UTC 2010
Here's my $0.02 on the deployment process we're using..
On Aug 31, 2010, at 11:31 PM, Andrew Nacin wrote:
> We all have our own processes for production deployments. It depends on the
> site, the client, the need, and of course our own preferences and tricks
> we've picked up. My process works well for me in almost every case, but that
> doesn't mean it'll work for you. (In a nutshell, I prefer to map the
> production domain to a local or remote sandbox. It's also how
> wordpress.orgis configured.) Again, how much of this depends on the
> developer's (or
> developers') own workflow?
I've been working on this solution using Ruby/Capistrano, my project is on Github (http://github.com/vluther/Autopress) my workflow is not perfect, but it's getting closer to how
I want it, I'd love it if people can help more.
1. cd to bootstrapPress (just a pristine clone of the github repo)
2. copy the comitted vmware.rb capistrano stage file in config/deploy/clientnametest.rb , make appropriate changes..
3. cap clientnamestest.rb deploy:setup, this does the following..
- ssh to localhost ,
- make web directory for client, do a git clone
- creates a mysql user with proper permissions for specific database
- creates specified database
- loads a default sql file from the git clone (un comitted versions have support for specifying a specific sql dump file)
- creates autopress.php , which is called very early in wp-config.php
- autopress.php has SITENAME, BLOGNAME, WP_USER, etc defined..
- creates all the secret keys/salts from http://api.wordpress.org/secret-key/1.1/salt/
- changes password of default admin user in the sql file we loaded (as specified in the stage file)
- uncomitted versions will even change the default admin username.
It's not the perfect solution, but it's working for us, I've deployed over 40 websites using this methodology
since I started the project.
I'm experimenting with the roles attribute in capistrano, where if it works the way I want it to, I could change my deployment
steps to be something like
- cap clientname deploy:stage
- cap clientname deploy:production
- cap clientname sync:stage (would sync production back to stage)
- cap clientname sync:production (would sync production from stage) (I'm not in a rush to automate this anytime soon :)).
I'm trying to find other people who are doing something similar, or have better methods that I could incorporate, I picked Capistrano/Ruby for this
as it's a very mature environment compared to Phing, plus people don't need to sacrifice anything to get PHP + SSH working on OS X :).
And, I wanted to learn Ruby, but not Rails :)
> Beyond that, I second everything Beau said. Thinking big will help, figuring
> out the real problems as well coming up with solutions, but before endorsing
> a deployment method there needs to be a lot more innovation and evolution in
> the space.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers