3

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!

Community
  • 1
  • 1
Joe Fletcher
  • 2,133
  • 4
  • 28
  • 33
  • Isn't that a security issue in that you have 3rd party code that you are committing back to your repo as *the* good copy? – Brill Pappin Dec 20 '12 at 23:39

3 Answers3

2

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.

Nic
  • 13,287
  • 7
  • 40
  • 42
  • Thx - this seems to complete the cycle from production to dev and back to production. The key here, as I understand it, is to make a commit from the production server to a repo somewhere. Then that repo is pulled into dev, explored, and then pushed back to production. I think that's the gist of what you're saying. – Joe Fletcher Aug 29 '11 at 20:48
  • You mentioned "user-changed files and data" - does that mean you are also tracking database changes through this process? – Joe Fletcher Aug 29 '11 at 20:49
  • Well, we're working with static files (as opposed to the database driven storage that WP does), so we track changes on those files specifically. We are exploring ways to version our database but haven't found an efficient way to do it. Ghost DB seems like a good place to start though. – Nic Aug 29 '11 at 20:55
  • Also, yes, you seem to have a grasp on how we use git. We love love love love our gitolite server and it is a really effective deployment. – Nic Aug 29 '11 at 20:56
  • Thanks @melee. That all really helps me put the pieces together. – Joe Fletcher Aug 31 '11 at 00:10
1

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.

manojlds
  • 290,304
  • 63
  • 469
  • 417
  • Let's see if I understand 2nd paragraph: have git installed on PROD, after plugin is installed, do an Add and Commit. Then on my local repo, I do Pull? Then supposedly I push to Beanstalk and optionally deploy back to the server to complete the cycle. – Joe Fletcher Aug 23 '11 at 22:50
  • 1
    @manojlds helped me out when I deployed git similarly. I have to agree here. Changes should be made in your development environment first, merged with the _local_ production branch, then pulled (or synced if you want to look at it that way) from the prod server. Does that make sense? – Nic Aug 24 '11 at 03:21
  • As far as I'm concerned, if you need to commit to your repository on the production server, you're probably doing it wrong. I would recommend setting up a development environment where you install, configure, and test plugins - and when they're stable, you commit them and redeploy the website. – Graham Christensen Aug 24 '11 at 12:05
  • I understand. But still, I'm trying to get to my original question about what to do when people install plugins through the WordPress admin, or upload photos, etc. What should be done then? Not every website is managed through a strict local dev production cycle. WordPress and other CMS's are built to be able to install plugins and upload images (etc) through the admin, so there should be an approach for these circumstances. – Joe Fletcher Aug 24 '11 at 16:04
  • I was under the impression that AWS DevTools was write-only. I don't even think there is a `git pull` function available. Or maybe that was what the question about to begin with . . . – jackweinbender Oct 30 '12 at 15:32
0

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.

Trevor A Green
  • 11
  • 2