Pick our brains...

WordPress and GIT Deployment Workflow

Let’s use this page as a place to flesh out an ‘official’ PM WordPress + GIT workflow.

Comments

  1. I’m initially hesitant to commit core WP files, or server specific configuration files (wp-config.php) into our client repos. As I’ve been thinking about things, it seems like there are only a few parts of a client’s WP site that we are actively changing and editing – client specific plugins, and their specific theme (see attached mindmap).

    In my mind, it seems like a lot of extra code to track (and download w/ git clone) in the client repo if we start tracking Core, or common WP plugins which simply point to a stable release. That being said, we need a way to make sure the current state of the production site is accurately reproduced locally.

    This breaks down into two parts of the state of the production server: 1) State of code, and 2) state of the DB.
    State of the Code

    What if we took Scott’s use of .gitignore further, and create a .gitignore that only includes the client specific plugins and theme, something similar to what is outlined in this post:

    http://danielkoskinen.com/version-control-and-deployments/

    which uses this .gitignore:

    https://gist.github.com/jdbartlett/444295

    We would then include a file that describes the state, something like a list of the name and version numbers of WP core, and any plugins active on the server. With this list of core and plugins, it is fairly easy to use wp-cli to setup specific versions of core, and any plugins needed.

    State of the DB

    And what about the content (posts, pages, etc) and design settings that some themes use that is located in the DB? Including a mysqldump in a commit seems like a ‘sort of’ good idea, but then are merges of these dumps easy/useful? I’m not sure, I haven’t tried that workflow.

    Alternatively, can we use WP’s export/import tools to export xml and commit that to our repo? Would that get any theme settings that are stored in the DB? I’m not sure.

  2. A few things we need here….

    Coming onto a git-based project, a developer needs to be able to do several things:

    o  Pull a fully working, intact codebase from the bitbucket, easily and efficiently.  Boomz.

    o  Be able to commit and push changes, both live and/or local.

    o  Coming onto a project, a developer should be able to easily tell if a project is version-controlled, by looking at the codebase and directory structure alone.

    o  In general, any file upload directories should be .gitignore’d.  Just about everything else should be version-controlled.

  3. So I spent some time yesterday thinking, and going through the motions of tracking and commiting WP things to GIT. The repo is shared, and can be found:

    https://bitbucket.org/peacefulmedia/wpgit-test

    The overview can be found on the wiki here:

    https://bitbucket.org/peacefulmedia/wpgit-test/wiki/Home

     

    This repo does not have DB info committed to it, so we still need to think of the best way of dealing with that. I personally pull down db dumps using wp-cli to export/import/search-replace urls:

    https://bitbucket.org/peacefulmedia/wpgit-test/wiki/WP-CLI%20Crash%20Course

  4. A reply from Lawrence Duncan and worth having in here….

     

    Awesome, thanks so much for the deep-think here BT!

    In my mind,
    we really do need to have server-side versioning capabilities.

    Let’s say we pico the wp-config, on the server.  Let’s say a designer updates a css file…
    We need to be able to both “git status”, and “git commit”, etc, straight from the server.

    Minor pain in the arse, I know.  Still, I think it’s necessary.
    We’ll need to figure out the best way of adding an authorized user to the repo, acting as the server.

    I’m thinking:  git@yourdomain.com as said user.

    And yes, I wonder how much of a complication this will be, in relation to the complication of uploading / downloading / re-uploading, figuring out files and timestamps and shit on live vs local.

    I like the idea of being able to status, push, pull, add, commit…   straight from the server.
    No strings attached 😉

    Lawrence Duncan
    Chief Technology Wizard

  5. ++ to “Coming onto a project, a developer should be able to easily tell if a project is version-controlled, by looking at the codebase and directory structure alone.”

  6. I’m checking things out and still wrapping my head around all this slowly! Will chime in with questions (wink)