How to deploy projects with Git

SFTP, SCP, rsync, or the classic FTP – there are many ways to deliver an app. The choice depends on many factors, such as the żworking speed, infrastructure limitations (some servers allow only FTP upload), or developer preferences.

A while ago (May 2017) we analyzed what our clients use for application upload: the clear winner was the FTP protocol, with SFTP and rsync only a half a step behind. However, in this post we'd like to talk about the fourth contender that only just missed the podium: deployment with Git.

The strong position of FTP most probably results from its popularity among WordPress and PHP developers, and the fact that many servers don't allow any other upload option. However, deployments over FTP have one serious flaw: modern front-end applications contain a lot of riles which means the upload can be very time-consuming, especially if you do it multiple times a day.

Git deployment

Let's get back to the point, which is Git. Every developer knows Git. If you want to pull the latest version of the repo, you run git pull. If you want to share changes with others, you run git push. Since only changesets are uploaded or pulled, these operations are very fast. However, many people don't know that they can deploy with Git just as easily.

Before we get down to business, though, let's remember one important rule:

---

Deploying with git pull

When setting up Git deployment to work with git pull, the setup is as follows: the server which runs the application also hosts a clone of the Git repository with the code. When it's time to deploy, you run git pull on the server to fetch the latest version of the app.

Setup

First, install SSH and Git on the server:

sudo apt-get install -y openssh-server git
$

Next, create a directory from which we'll serve our app, and initialize it as a Git repo:

mkdir ~/www/app.com
cd  ~/www/app.com
git init
$$$

Finally, connect the directory you initialized in the previous step to the repository with your code by adding a remote and pull the application:

git remote add origin {YOUR_APP_REPO_URL}
git pull master
$$

Release

Releasing the app is simple - connect to the server, change path to the directory with the app, and run git pull to download the latest version of the code to the server.

Then, if the application requires building (fetch dependencies, compile assets, generate artifacts, etc.), execute the build command manually on the server (npm, composer, yarn install, gulp grunt webpack, etc.) just as if you were working on your local machine.

Rollback is easy, too: just check out the revision to which you want to revert and build the app again.

---

Deploying with git push

Deploying with git pull required connecting to the server and executing all commands manually. Now let's take a look at an approach where all it takes to release your app is to run git push on your local machine.

Setup

The first two steps of the setup process for this flavor of Git deployment don't change. First, connect to your server and install SSH and Git:

sudo apt-get install -y openssh-server git
$

Next, create a directory from which the app will be served, and initialize it as a Git repo:

mkdir ~/www/app.com
cd  ~/www/app.com
git init
$$$

Git config time! Run these commands to configure Git to allow for ref update to the currently checked out branch and set the worktree to the directory with the repo:

$ git config receive.denycurrentbranch ignore
$ git config core.worktree ~/www/app.com

And now, the main course: creating a post-receive hook which reacts to git push. It'll check out the new version of the repo and build the app if needed.

Enter the edit mode with nano:

nano .git/hooks/post-receive
$

and configire the hook:

## !/bin/sh

## checkout HEAD

git checkout -f
## fetch dependencies and build

npm install
gulp

Finish off by making the hook executable:

chmod +x .git/hooks/post-receive
$

Done! Time to switch to your local machine and set the process in motion.

Release

We're going to deploy the new version of the app right from the repo. All you need to do is to connect it to the same remote you used on the server. This way when you push changes to that remote, the server will "see" the activity and execute the post-reception hook you set up.

Let's assume we're deploying to the production server:

cd ~/repos/myrepo
git remote add production ssh://user@ip/home/user/www/app.com
$$

Releasing the application looks exactly the same as pushing local changes to the remote:

git push production master
$

---

Pros and Cons of Git deployment

The major pro of Git deployment is definitely the release time of every next version of the application: it's fast, because you're working with changesets only.

On the other hand, an app updated with changesets needs to be built on the server. The time you save is offset by the downtime caused by pulling the dependencies and building the app. Moreover, an application should be tested both before and after the deployment, which adds even more manual steps to the process.

Is Git better than FTP or SFTP? It certainly has its advantages – the setup isn't overly complicated, and small projects can be deployed fast and without hassle. However, if your website employs any modern web framework, you will almost certainly benefit from introducing some sort of automation to your delivery process.

Thanks for reading!