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.
Contrary to popular FTP clients, Buddy's deployments are based on changesets, which means only modified files are uploaded to the server. This significantly shortens the upload time, as you don't need to deploy the whole repository on every execution.
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.
In this article, we'll describe how to configure a server to release an application with git push and git pull.
Before we get down to business, though, let's remember one important rule:
Never keep dependencies and compiled artifacts in the repository
We have covered this in detail in the article about building and deploying front-end applications, an essential read if you plan to automate the delivery with a CI/CD tool like Buddy.
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$$
The best practice is to create a new user on the server and grant them access to the repository provider (GitHub, Bitbucket, GitLab, etc.). You may check this article for more details.
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.comAnd 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
gulpFinish 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.
Git hooks are a powerful tool that can help you inject automation to your projects, a proper step towards DevOps implementation. To learn more, read the official Git hook documentation.
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$$
The authorization is performed with SSH. In our case, it's the same user that we used to perform the setup.
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!
The whole Git delivery workflow can be automated with Buddy's pipelines by either adding the Git push action or running git pull over SSH on the server. You can also use an atomic deployment template to eliminate the downtime.
