Mark Jaquith has a couple of videos on WPTV that give a high level overview. He also has WP-Stack on Github as a model Capistrano deploy for WP. Itās enough to get started and get a feel for what works and what you need to build yourself.
Iām a bit concerned by his position that the media assets donāt need to be versioned. If the customer changes their logo and overhauls their site and the new logo is a different size, it seems like rollback without the ability to rollback the media would create appearance issues.
There are other solutions as well. One of the guys from the VVV team has Salty-WordPress, which uses SaltStack to set up something like a VVV vagrant. I looked at SaltStack long enough to determine it could be used for software deployment.
Thereās also Ansible, which can do server provisioning and software deploys and requires nothing but Python and SSH on the target server. (Iām exploring Ansible more because I donāt know Ruby and YAML is easy to writeāamong other features.)
Iām a but curios about this aswell.
From what I gathered I should be working like this:
Develop locally and commit to develop branch on remote repo (bitbucket in my case).
Pull the dev branch to my online dev enviroment, which I intend to use to
keep the client up to date with the current status.
When project is nearly done, merge develop with another branch, called stage branch this branch is then pulled into the stage enviroment. Stage is on the clients server. In this scenario the client will start to replace my dummy content with the real deal, this is the first time the clientās allowed to login and make those changes themselves.
Now here is where I think it becomes tricky. Because ideally I will let the client work with the stage enviroment before itās moved onto production. Thus Iād like to pull the db from the stage to my local setup regularly so that I have live media and text content so that my dev enviroment is as close to the real stuff as possible. But since I wonāt be version controlling the media, this wonāt work. So how should I do it?
I think for stage to development, you could just copy the database (dump, copy dump, load, use a search and replace script to fix links). Hereās one solution http://interconnectit.com/products/search-and-replace-for-wordpress-databases/ that Iāve tried. There are others I havenāt tried. WP-Stack seems to script production to stage minus the search and replace (see namespace :db in lib/tasks.rb). You could use the same process for stage to development. (Yes, itās Ruby, but the important parts are shell commands.)
The bigger challenge is moving to production. Ideally, all changes should be done with SQL scripts so theyāre repeatable, controllable, and versionable. (Certainly true if youāre talking 12-factor.) At initial load, that isnāt a big deal (production database is empty). The second load, though, you have to find what changed and script the changes. (Iām still trying to sort out how you make that work without a lot of manual intervention. There are some database compare tools out there that should help, but I havenāt found the ideal answer.)
Also, would you really let clients develop in staging? I thought staging was supposed to be user acceptance testing, which should mean no changes to staging that donāt go through development and unit testing first. You might have an exception case for a blog segment of the site, but the non-blog site should be controlled. If clients are creating content, shouldnāt that should be in another development environment with changes versioned into a script and pushed to UAT-staging?
As far as media, I think itās completely possible for media to break a site or at least make it look horrible. If you canāt rollback to the previous version of media, youāre stuck. I think you have to version media somehow. Maybe not git. Maybe the deployment preparation process identifies changed files and puts them somewhere the deploy process can find it (and can backup the corresponding files), but some kind of packaging and versioning so you can revert in a crisis.
Hm, not sure. Iām new to all this.
But would it be better to bring in the client at production? I rather let them add all their content, rather than having me organize that for them. Itās also a good way for them to learn using Wordpress.
I guess you could move up to production and protect the site with htpasswd while theyāre add their content. But then you wonāt be able to have a placeholder site at the same time (if adding content takes along time, thatās not so good).
The situation Iām envisioning is four environments. Vagrant for the web developer, Vagrant or content-dev.xyz.com for clients developing content, staging.xyz.com for user acceptance testing, xyz.com for production. The client-dev site can be a vhost on the same site as staging if needed. The trick to making that works is some kind of tool to package the database changes and clean up revisions, or work in progress before moving to staging and production. (This is one of those areas I want to research more, but havenāt gotten to yet.)
Many sites I see in the gallery look like they have rarely changing content. In this case, thereās no reason the client couldnāt provide the copy and the developer install that copy in the site (create posts/pages). If thereās a blog/news component or other dynamic aspect, itās possible to identify and isolate that data and manage it appropriately. If the client wants to edit copy directly, see paragraph above.
The client selling point is control and security. See [HMVās Twitter debacle] (Inside HMVās Twitter Disaster: What went wrong (and how to keep your company safe)) and imagine someone doing something similar on the clientās site. That isnāt an issue if youāre dealing with a sole-proprietor client, but if the client organization has several employees and someone other than the owner/CEO is doing most of the site management, the owner/CEO or his highly trusted designee should check content before it goes into production and should want content migration to happen in a way that it canāt be changed after s/he approves it.
The same rationale raises the question, do you really want people to be able to comment on your pages and posts?
EDIT: Yes, WP has a contributor/approver system. Iām still not sure I would want to see edits happen in production if I could find an efficient way to extract the data and move a script instead. Some long-winded, non-copywriter decides to rewrite a finely tuned 50-word paragraph into a 750-word babble that breaks the flow of the site and SEO. (My real job is in a very risk-aware organization where nothing goes into production without careful controls, so I tend to be paranoid about this kind of stuff.)
WP-Stack was great when it first came out but itās a bit behind the times. The way he uses Capistrano isnāt great and itās also using the old v2 version. Capistrano v3 is much simpler, faster, and better. Thereās also nothing Rails specific in the core Gem anymore which is great.
The āstackā that weāre working on is Chef based but Iāve also been thinking of switching it to Ansible. Itās much simpler and easier to use especially if you donāt have Ruby experience.
My main interest in WP-Stack (after the Ruby nightmare @_@) was sorting out what it did so I could replicate it in something else.
I know enough about Ansible to be dangerous. Iām building a set of roles to prepare a WP-ready web server on Debian based on VVV in my evening research time. Parts of that could probably be easily modified to align with your Chef.
My real job gives me vacation, and I have most of it scheduled in December, so I should have some time on my hands that I can throw toward helping out with an Ansible experiment if youāre interested.
This has to be my favorite topic in Roots by far. Learning so much just in 1 topic itās crazy! Not to mention the awesomeness of Roots itself.
And then I have to mention Bootstrap. WordPress. On and on and on. OSS is too awesome.
Iām nowhere near you guys with this workflow and itās been great to learn a lot from this topic. Canāt wait for @swalkinshaw updates about Caps. I canāt do much to contribute but I do use Pagodabox.com for most of my clients. If thereās anyone using that (or interested) I can write and share my QuickStart recipe and some stuffs I learn the hard way working with PB. Iāll say those who use WPengine and love the git-based workflow might consider PagodaBox as one of the alternatives for their tools.
Canāt wait to see the wp-stack but just what Iām using at the moment:
wp-migrate-db-pro plugin to move the database around
Using grunt ftpush to deploy the project (only the appropriate folders) to my server, this stores the changes a bit like git so it only pushes up new changes.
Probably not the most optimum setup but it works pretty well. Going to look into ansible now though.
@swalkinshaw Hi Scott, I was wondering how the new screencast is comming along. I have a new website pending and would love to use what you can teach us for the new deployment.
For those waiting on the screencast, Iām 90% done and it looks like Iāll break my promise a bit but the screencast should be up in the next day or two. Unfortunately itās always the editing and final publishing that take the longest
Sorry for the long wait but making these screencasts is actually pretty time consuming! Iāll probably start a separate thread for feedback/questions about it.
Keeping databases in sync in my opinion is one of the more difficult challenges to solve, yet least talked about on forums about deployment. After a ton of different approaches, hereās what I recommend:
WP Migrate DB Pro If youāre a WP developer, itās one of the best ways to spend $99. It is SO easy to push and pull databases between local, dev, prod, etc., including updating URLs that have been serialized in widgets. You can push the entire db, or select which tables. This helps if you simply update the wp_options table or wp_posts/wp_postmeta. The only downside is that currently you need to run it through a browser in the WP admin, but they are potentially working on a command line solution. They also have a beta add-on for keeping media files in sync, due out in the main plugin soon.
The next best option is to set up wp-cli. This allows you to run WordPress commands via the command line, and you can hook in and create your own. It has a built in search-replace function to update URLs & serialized data (it actually used the interconnectit search-and-replace mentioned elsewhere here). What I do to prepare the database is to use the search-replace function to update the URLs, export it via wp-cli, and then take that dump.sql and import it into the target database somehow. Easiest is via phpMyAdmin or Sequel Pro. OR, I have also written simple scripts that SCP the dump to the server and then import it via mysql command line.
Use interconnectit search-and-replace in your project. This has a browser base or CLI option. Iāve used the CLI as a part of a custom deploy bash script.
Use WP Engine. They have a push button production to/from staging setup which also allows for full or table-based db migration. Downside is that you still need to do one of the other options above for deployment to/from local. And, if you want to do any of the great Capistrano kind of stuff mentioned in this post, you are out of luck with WP Engine since they do not allow SSH access.
Keep in mind that Capistrano v3 was rewritten and no longer has anything Rails specific in it. You actually need to require Rails gems for it if you want. v3 is generally must better, simpler, and faster.
