How to deploy a website using Git

Using version control is an excellent way to track changes to your app, control who access to be able to work on it, and manage how features are developed.

However, a difficult step to overcome can be how to get your code from your repository over to your servers. Because version control systems such as Git don't have a particular interest in this side of your development methodology, you'll need to choose a way of working that best suits you. We'll outline a number of popular deployment methods below and their advantages and disadvantages.

Direct uploads

Arguably, the most "traditional" way of deploying your code is also the most simple. It consists of the developer connecting to their server directly, most likely via FTP or SFTP, and simply copying (or dragging and dropping when using a GUI such as Fillezilla or Cyberduck) files from their local copy of their code to the server.

This is quite reasonable for a solo developer just working on their own apps, but raises a few concerns when working in a team.

• Can I be sure I'm deploying the latest and correct version of our code?
• How do I make sure I'm uploading the correct files without having to upload the entire repository?
• Will there be downtime while I'm uploading files, and what happens if someone else tries to upload a change at the same time?
• If something breaks in my app after uploading my code, how do I easily rollback?

If at all possible, this method of deploying is strongly discouraged.

Using version control on the server

Nowadays, a more common way of deploying your code is by using your version control system directly on the server.

With Git it's quite simple. Push your work to the remote repository when you're ready, then login to the server, navigate to the directory that contains your app, and run git pull to update the app with your your latest changes.

$ cd /var/www
$ git pull
remote: Enumerating objects: 19, done.
remote: Counting objects: 100% (19/19), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 19 (delta 6), reused 9 (delta 5), pack-reused 0
Unpacking objects: 100% (19/19), done.
From github.com:adamw/mysite
   dcba4321..1234abcd  master          -> origin/master

This helps to solve a number of issues with direct uploads, ensuring that only the correct files are uploaded, and minimising downtime by using a compression method to quickly update the repository copy on the server. Additionally, if there is an issue with your app after pulling your latest changes, you can fairly easily rollback to a previous, working commit with a couple of simple commands.

The two main drawbacks of using Git to update your site is that a) You need Git on the server to be able to do it - a lot of shared hosting platforms are very unlikely to provide this support and b) It just does what it's designed for - updating files, not doing other things that modern web application development requires such as database migrations or code compilation.

Using a dedicated deployment process

Finally, you might choose to use a dedicated deployment service or script that will effectively take care of the whole process for you.

Deployment scripts

Firstly, deployment scripts are a useful way of creating a deployment recipe that you can use repeatedly for more than one site or app. A popular app that uses deployment scripts is Capistrano.

Capistrano is a deployment app, written in Ruby that is designed to take care of a number of useful aspects of deploying your code as well as even more features than just using Git or direct FTP, including arbitrary commands (such as restarting services, database migrations or code compilation) and the ability to deploy to multiple servers at once.

It even uses an "atomic" strategy whereby everything is deployed to a separate location from where you live site is actually running, then once this process has completed the site gets "switched" from one location to the other using a symlink. This means no downtime.

Everything in Capistrano is configured in script form by creating a Capfile that lives in your repository, meaning any developer with the appropriate access can deploy from the local machine to their server.

$ cap deploy production
deploy
  deploy:starting
    [before]
      deploy:ensure_stage
      deploy:set_shared_assets
    deploy:check
  deploy:started
  deploy:updating
    git:create_release
    deploy:symlink:shared
  deploy:updated
    [before]
      deploy:bundle
    [after]
      deploy:migrate
      deploy:compile_assets
      deploy:normalize_assets
  deploy:publishing
    deploy:symlink:release
  deploy:published
  deploy:finishing
    deploy:cleanup
  deploy:finished
    deploy:log_revision

Really, Capistrano does everything a modern web application needs to get it deployed efficiently, but you need a server that can run Capistrano, and also some technical knowledge to be able create the Capfile.

Using a deployment service

A lot of creative agencies find themselves managing websites for a variety of clients that use different hosting platforms, with a different set of supported tools and capabilities. Some clients might have their website hosted on a shared server that only has FTP access, and others might have a dedicated server or VM that provides full access to all terminal functions.

Managing the deployment of your code easily across such a differing set of clients can therefore be difficult and potentially, you'd might need to use a combination of all of the above options, FTP, Git and even something like Capistrano to support all of your customers.

However, by using a deployment service such as DeployHQ, you can manage all of these clients by creating a project for each app, adding servers to deploy to and setting up a "recipe" of different elements to help with the deployment of each one.

You can deploy from any Git repository to almost any server, whether that be via SSH/SFTP, FTP or other protocols such as S3. Additionally, if you have build tasks to run such as code compilation, they can be run on DeployHQ before the changes are uploaded, allowing you to keep compiled outside of your repository even if you're limited to only an FTP connection to your server.

Additionally, with the major supported repository hosts such as Bitbucket and GitHub, you can setup automatic deployments so that your changes will be uploaded for you when you push to the repository.

Take a look at our features page for a list of the most useful things DeployHQ offers to make your deployments even easier.