Search code examples
gitwordpressversion-controldeploymentamazon-elastic-beanstalkbeanstalk-svn

Git, Beanstalk, WordPress Ultimate Deployment Approach


I'm using Git and Beanstalk to develop WordPress locally and then deploy to the production server with Beanstalk's deployment process. But how do I sync changes that are made on the production server back to my local development / git repo? Changes on the server will happen anytime someone installs a plugin. Is there a way to pull those changes back into local?

I appreciate any help with a Beginner's understanding in mind. Thanks!


Solution

  • I run a CMS, and as I said in the comment, I got my workflow setup with the help of manojlds. I wanted to expand upon our implementation in hopes of helping you out with user created content.

    I setup gitolite as our remote repository. It rocks.

    Our branching model works like so, with WordPress as the context:

    master - # this is the _vanilla_ install of wordpress with no modifications
    prod - # the branch that the production server pushes/pulls to
    dev - # dev environment pushes/pulls to, in our case a server
    alpha - # really early development, ideas, etc - my personal branch that i work on mostly
    features (opt) - # as needed, I'll make feature branches then merge them into the other branches.
    

    Our prod, which handles about 40-45 different static files per day, has a cron that automatically adds/commits user-changed files and data on a daily basis. That picks up all of the user-based changes, and would (in your case) pick up plugin installs. This is great because you have history on their installs.

    Actual changes to the codebase are usually explored in alpha, then merged up to dev. We've created some hooks where when we push to the dev branch, the dev server automatically pulls the new commit in. Then they're synced.

    After it has been tested in the development environment, I sync my local production branch with the remote, which as stated, gets a user-content commit every day. Then I'll merge or cherry-pick the commit into product, then push to prod on gitolite. After that, the prod server pulls and everyone is happy.

    This sounds like a lot of work, but it's actually been very effective, especially after some hook scripting. I'm still in the process of tweaking our deployment (for example, I can almost completely get rid of the alpha branch and work off of dev/feature locally), but we get an awesome bonus in actually having daily snapshots of the production server, and the ability to sync all of the branches at any time.

    Also, regarding your master branch - leaving this as the vanilla install of WordPress is awesome, because you can actually test new version upgrades easily. You could just checkout master then run the update, and slowly integrate customizations.