Production and Development environment sync

Question

Hi, 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?

Answer 1

I would normally expect to keep git for your development environment.

Your build would construct some deployable (a .tar.gz, perhaps) by specifying a tag to build against (such that your build is audited and repeatable) and then you'd copy that across to your server using ssh/scp.

I wouldn't just sync from a development environment. You want that for stuff in development, stuff you're experimenting with, supporting tools and files etc.

Answer 2

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.

Answer 3

Capistrano, originally built to deploy Rails applications in particular, has since been extended to deploy any kind of web application (called a rails-less deployment).

Once you set it up, the workflow looks like this:

1. Edit the source of the program.
2. Check-in your changes and push them to the central repository (git/mercurial/svn/whatever)
3. Run cap deploy on your program.

Step 3 is where the magic happens, and this is what Capistrano was built to do. Capistrano will check out a new copy of your code from the repository, copy that code to a new "release" directory (named something like 20091028230834, a timestamp) and finally link the directory current to your latest copy. In the middle, it may run migrations if they exist. You're left with a directory setup like this:

...deploy-to-path/current  ->  ./releases/20091028230834
...deploy-to-path/releases/
    20091028230834/
    20091028225623/
    ...    # You can configure the number of releases kept after deployment.
...deploy-to-path/shared/
    cached-copy/  # A cached copy of your repository, which Capistrano updates
    ...           # Any shared data, like file uploads, for your application.

The documentation for Capistrano is not great. They really need someone to come along and write it cohesively. Essentially, though, what you're doing is writing a file (deploy.rb) with the following information:

• Where is the server? (e.g. www.example.com)
• What are your ssh credentials? (user, password)
• Where is your code stored? (your repository URL)
• Where do you want the code on the server?

To get started, I suggest running capify on your application (giving yourself the default files) and running it on a test server (or a test directory on the server) to see what it does. Once you get it deploying something, you can customize it to do extra moving/symlinking of things.

Answer 4

You should have an automated build from a source code repository for both your development and production builds.

You should also have an automated script to deploy in development and production environments.

Then, to deploy to production, it is a simple matter of checking in your dev code, running your build script, then running your production deployment script.

This holds regardless of what software/environment/tools you are using.

Answer 5

You should also think about how you want to release stuff...pushing a continuous dribble of changes out to production can make it very hard to track down when a problem cropped up.

As others have mentioned, you can use git to sync to manage your code. When you have a new set of changes that you think are ready, those can go in a branch, or at least tag them so you know what set of changes went out together.

Then you can sync those changes out to a staging directory, and flip the switch when thins have been validated there.