Search code examples
gitdevelopment-environmentsynchronizationproduction-environment

Production and Development environment sync


I have a web app on my computer and on web server with ssh. The problem is that I`m developing the app locally on my computer and I want to sync it with the server not by copying files via ftp. Is there any other way? git?


Solution

  • You don't specify what OSes or languages are involved, so that makes it hard to be specific.

    Git (and SVN and Mercurial, etc) is great for version control, but keeping systems in sync often requires more than version control. If you are a Python type person you might enjoy reading Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip. This talks about keeping not just code but your entire environment in sync.

    For simply keeping files on two systems in sync, I recommend rsync. I use this for all sorts of tasks, both on a single machine and for backing up/syncing directories between machines. We have a customer in SoCal where we are doing a 3-level backup strategy (2 on site, 1 off site) of over 5 terabytes of data and the heart of it is rsync and rsnapshot.

    Update for comment:

    It doesn't really matter what your site is written in, you still have to make sure that all of your changes make it up to production. This is often a multi-step process. Fabric is specifically designed to encapsulate these steps and reduce them to a single command. Pip and virtualenv are more Python specific in capturing additional library changes, etc., but Ruby/Rails probably have something equivalent. The goal is to have a single command everything necessary to go from dev to staging, and another single command to go from staging to production.

    A word of caution: Do not auto-sync directly from your dev machine into your production directory. Always go to an intermediate staging directory on the production machine first. It's almost certain that the two machines do not have 100% identical environments and what works on dev may not work at all on your production machine. It's better for you to take the extra minute or two to test in staging rather than cause your entire production site to go 500 error.