Our WordPress development process

After a recent launch a twitter follower asked how we manage development and I replied:

@SeamlessThemes Locally first, then create a dev site subdomain for data entry. All synced with git, beanstalk, and wp migrate db pro

— Bryan Hoffman (@spigot) August 9, 2014

He then asked for a writeup. So let’s talk about how we develop WordPress websites. These are the steps we use in the development phase of a project, which follows the design phase, which follows the research & content strategy phase…

Here’s a quick list of our development steps:

1. Set up remote Git repo at Beanstalk
2. Clone repo locally using Tower
3. Set up MAMP local virtual host & database
4. Install WordPress
5. Add starter template & plugin set
6. Add .gitignore file to repository & initial commit
7. Add site to Codekit & activate theme 
8. Build.
9. Set up staging server and migrate site
10. Hook dev site up to Beanstalk deployment
11. Add WP Migrate DB Pro to manage database sync. Pull only! from dev site to local
12. Continue development locally while data entry happens on dev site – Pull down db when necessary
13. Client sign off and launch.
14. Run post launch tasks

1. Set up remote Git repository

We use Git for version control, and we host our repositories with Beanstalk. Why Beanstalk? One simple reason, really: deployments. Beanstalk allows us to automatically deploy commits to remote servers, and I don’t need to fire up Terminal or know what Capistrano is to do it.

Create a new, empty repository on Beanstalk, then clone it to your local machine.

2. Set up local repository

Once the remote repo has been created, clone it to your machine for local development. If you’re a wiz use the command line. If not, use a tool like Tower. I’ve tried both and am just not comfortable being in the command line all the time. Tower just released version 2.0 and it seems much more stable than 1x.

3. Set up MAMP

Update: We’re now using Vagrant as our development environment over MAMP. Not sure when we’ll have a writeup on it, but you can search here: Spigot: Vagrant

Since we’re developing locally, we’ll need the full site running. With WordPress, this means Apache, MySQL, and PHP. MAMP Pro is the tool we use because we’re GUI like that. I’ll usually create a local site domain like: example-site.loc as a naming convention. Note: be sure not to use .local as I did at first. The site will work but slowly as that extension is used by OS X. Point this domain to use the same directory as you cloned the git repository in to.

You’ll need to create a database with MAMP as well. Just create a fresh one and remember the name. If you use default MAMP settings the username and password will be root.

4. Install WordPress

You know how to do this. If not here’s the 5 minute install.

5. Add starter template & plugins

We start nearly every project (99.9%) with our own starter parent theme, Infusion. It’s a blank skeleton theme built using Hybrid Core framework by Justin Tadlock, is Sass ready (with Bourbon), and is schema.org ready, mostly. It’s there to use, if you like.

I used to use  Compass, but switched to Bourbon for Sass mixins. No Ruby dependency and it compiles fast. Plugins… we’ve got our list, I’m sure you’ve got yours. I could do a favorite plugins list, but everyone seems to have their own list.

I update screenshot.png at this point, branding Spigot a bit. Not that a single client has ever ventured to the theme page to see it, but still…

6. Add .gitignore file to site root & commit

You don’t want to have the entire WordPress install loaded into your repository. Use a .gitignore file to manage what gets tracked. If using Infusion, there’s a sample gitignore.md included in the Infusion docs, which is based off of this gist. Edit the file to match your project, move it to the root and don’t forget to change the file name from gitignore.md to .gitignore. You may need to do this with a text editor, OS X won’t let me change it with Finder.

At this point, I run an initial commit through Tower. I just like to have that fresh starting point in Git. I don’t think I manage my commits very effectively, or comment adequately, but this initial commit is a solid choice. I think.

7. Add site to Codekit & activate theme

We use Codekit to compile Sass. It’s fast and short on the learning curve. I gave Grunt a try for about a week, and while I can see the potential, I can hardly be bothered to stay in Terminal that much. I wrote a post about it if you’d like to know more.

Once Codekit is up and running you can activate the theme. Here’s the steps if you’re using Infusion:

1. Rename the Infusion folder to something relevant. I use the client’s name most often.
2. Open `style.scss` and rename the theme there. Change up the rest at will. Save and Codekit should compile.
3. Browse to Appearance > Themes and activate your theme. Hopefully your fancy screenshot makes it easy to find.
4. Bonus step: Rename the text domain in all files from Infusion to something unique and project related. I use Sublime Text to do a search and replace across files.

8. Site Development

At this point your normal local development process can kick in. Design comps and wireframes, oh my! And remember, Git is your friend, save, commit often, and push to the remote server.

9. Staging Server & Site Migration

Once the site is developed to the point where it needs to be seen, we push it to a staging server. Most often this is a subdomain on our server, but sometimes not. It just needs to be somewhere semi-public where the client and data entry folks can get to it.

We use Backupbuddy to manage site backups, and until recently it was the quickest way to migrate a site. I’ve been running into issues with that lately and have resorted to a simple file/db dump to the server, as told here: Moving WordPress. Not as quick, but it works. (Hey iThemes, how about a fix?).

A couple of quick edits to the database and the site should be up on the staging server. I sometimes find that running a Search & Replace on the database will fix URL conflicts.

10. Beanstalk deployment

Log into Beanstalk, browse to your repo, and set up deployment to the staging server. This will allow you to continue developing locally, push commits to Beanstalk, and have them automatically (or manually if you choose) pushed to the staging server. Beats FTP.

If you’re working with multiple developers you’ll do this step much earlier. You’ll do the next step much earlier as well.

11. WP Migrate DB Pro

Keeping files in sync is pretty straight forward with Git and Beanstalk. But what about the database? For years I relied on a periodic data dump to keep my local site in sync with the staging site. It’s rare that a database slightly out of sync will affect the development process after all. But as teams grow, staying in sync becomes even harder. WP Migrate DB Pro is a WordPress plugin that allows for quick and easy database sync. We use the staging site as a ‘master’ of sorts, and only allow the database to be pulled from and never pushed to that site. If you’re not careful and allow a free for all, you may end up overwriting someone else’s work. Trust me, keep the gate closed here. Pull only from the remote site. Thankfully the plugin has the option to manage pushing and pulling.

12 Data entry & site review

We normally require the client to provide content, but we’ll do the initial entry. We’ll get as much content added to the site as we can, then finally show it to the client. The client now reviews and requests changes.

BTW, data entry is where my warnings about syncing databases really comes to play. Did I mention pull only?

13. Launch!

Once the client has signed off it’s launch time. First things first, crack that IPA, or 100 year scotch, or nearbeer – what ever aids you. You’ve come a long way and you deserve a moment to celebrate. If this is your first launch you don’t need this reminder, but after a while launching a site can become just another task. Let’s not let that happen.

Migrate the site to the production server as you did to the staging server. Celebrate some more.

14. Post launch tasks

We’ve got a short list of automatics for post launch:

1. Make sure the privacy settings are correct in WordPress. Let the spiders index!
2. Turn on Jetpack stats
3. Set up Google Analytics.
4. Add site to Google Webmaster Tools. Submit a sitemap. If I’m feeling extra extra, I’ll do Bing too but not usually. Not sure why.
5. Encourage client to sign up for our maintenance program

And that’s pretty much it. I’m sure there are minor steps that I’m forgetting, but this is the base. I’ll keep this post updated if things change. If you’ve got questions regarding any step, or a task needs clarification, just ask in the comments. I’ll try to elaborate or clarify.