Git, Beanstalk, WordPress Ultimate Deployment Approach

3 Views

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!

Post Views: 3

Related posts

Leave a Reply

3 comments

  1. 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.

  2. Changes should ideally not be done in production in my opinion. Can’t you look at a way for installing plugins whereby you add the plugin to the git repo and push it to prod? I understand that you are probably talking about installing the plugin from WordPress UI which adds it to PROD, but I feel you should get the plugin content, add to your repo and push to PROD.

    If that is not possible at all, you have to make sure that the plugin content is committed when a new plugin is installed in PROD and then you can git pull the content to sync.

  3. I think that the short answer is that this process is broken with wordpress.
    I haven’t yet found a solution where wordpress, accessed through ftp, can have its changed files added to a repo and become the new version.

    Let me take that back for a minute. I mean with out user intervention. If you map your ftp as a drive and/or snyc your production site back to you machine in your trunk and then commit the changes, you can get the things happening on you wordpress production server back into your repository.

    Short of removing all of the nice features in wordpress that allow users to do what coders consider bad practices, there should be a solution for this. I’m using beanstalk, and I would love it if, in addition to deploying to a production server, I could tell it to automatically add changes from the production server back the repo and notify me of changes. Then I could go and diff whatever is going on and if its a problem redeploy from a previous version.

    As is, the situation is limiting and requires more work. I suppose I could try and build my own automated pull and checkin mechanism but that sounds tiring. If anyone knows a better way (besides running servers with SSH) I’d be interested to hear the solution.