How to Handle Distributed Development Workflow

2 Views

I’m trying to come up with a workflow for two (right now) people. One of whom will be doing theme work and another who will be writing content. We are not co-located are will not be anytime soon.

The writer is quite unfamiliar with source control, so that would best be a phase two kind of thing. I could put MAMP on her box and have her write there, if that is the approach, how best to integrate the two solutions?

Read More

I’ve read this question: How to best setup for development for a two person bi-coastal team? but since it is two years old, I thought I would see if anything has changed.

Post Views: 2

Related posts

Leave a Reply

1 comment

  1. Caution: very mac/linux/unix centric thoughts ahead. Includes a lot of command line fu.

    Put All the Code Under Version Control

    I like git. Mark Jaquith has some good suggestions on keeping an entire site under version control using git and submodules for the WordPress core. You could also put plugins in as git submodules.

    The developer end of the team will work locally, test and commit any changes, then push the code to a central repository (Github with a private repo, Beanstalk, Your server, it doesn’t matter). From there you can use deployment tools (Capistrano, etc) or simply SSH into your development server (see step 2) and git pull in your changes.

    Be sure to add your static file directories (eg. uploaded images and content) to your .gitignore file.

    Set up a Development Server

    Eg. install WordPress on a subdomain of your main site, like staging.yoursite.com or dev.yoursite.com. This is testing ground for new code and where your content producer will work. I’d recommend keeping this on a separate sever entirely.

    Give your content product a username and password to the staging site, and have them produce and write all the content there. You’ll also pull in the latest code changes to this site to test here before pushing them to the production (live) site.

    From the development server you can do a hard database export and use that to put all the content on the live site.

    On the dev server:

    shell$ mysqldump -p -u your_dbuser yourdatabase > the-file.sql

    Send the file over the production server and…

    shell$ mysql -p -u your_dbuser your_database < the-file.sql

    There is another alternative that I’ve just recently had the pleasure of working with called RAMP by Crowd Favorite. It will deploy content from one server to another for you. It is awesome. Highly recommended.

    When everything is ready to go, push content and code to the live site.

    As a final word of caution: IP restrict your dev site so not everyone can access it.

    Syncing Your Local Development Site

    Obviously if you’re goign to work locally, you want to keep your local site in sync with the development and production sites. All your code will be under version control, so that’s no problem. But syncing the database and static files is another matter.

    Syncing the Database

    Two options here.

    1. You can SSH into the dev server every no and again and dump the database into a file that you can download and import to your local machine. Use the commands above.
    2. If your host allows external database connection, create a user that has read only access to your dev site’s database. You can then specify a host argument with a mysqldump command on your local machine and dump the database onto your machine directly — I do this with media temple.

    Example of mysqldump with a host.

    shell$ mysqldump -p -u your_dbuser -h the-externa.db.host.com the_database > the-file.sql

    You can also just log into your hosts PHPMyAdmin and export from there.

    Syncing Static Files (Uploaded Images, etc)

    rsync is your friend. It allows you to do delta updates from one location to another, including over SSH. In other words, you can use it to download only the files you don’t have your local machine.

    Example:

    shell$ rsync -avze ssh your_user@yoursite.com:/path/to/static/files/ /path/to/your/local/static/files/

    Assuming your host uses passwords for SSH access, you’ll be prompted for a password after running that command. If your host doesn’t do that, eg. uses passwordless, public key SSH access, you’ll need to jump through some hoops with a little shell script that uses ssh-agent:

    #! /bin/bash

eval "$(ssh-agent)" # start ssh-agent user daemon
ssh-add /path/to/your/id_rsa # add your public key

rsync -avze ssh your_user@yoursite.com:/path/to/static/files/ /path/to/your/local/static/files/

kill $SSH_AGENT_PID # kill the ssh agent

    You can also use rsync to keep the static files in sync between your production and development servers.

    The above is how I work with my personal sites and with a few client’s sites.