Stop FTPing: Architecting Zero-Downtime Deployments with Git Hooks

Date: August 1, 2014
Author: Magnus "The Hammer" Larsen, Senior Systems Architect

If you are still using FileZilla to drag-and-drop PHP files into a production server, stop reading this and go rethink your career choices. I’m serious. In 2014, with the tools we have available, manual deployment is not just lazy; it is professional negligence.

I recently audited a large e-commerce setup here in Oslo—I won’t name them, but let’s just say they push serious traffic through NIX (Norwegian Internet Exchange). Their deployment strategy? A junior dev manually scp-ing tarballs to three different web servers. The result? Sync issues, downtime, and a database that was writing to a schema that didn’t match the code. Total disaster.

Today, we are going to build a Git-Driven Infrastructure. Some people in the Valley are starting to call this "Infrastructure as Code," but I prefer to call it "Sanity." We will use Git as the single source of truth, automated hooks for deployment, and reliable KVM hosting to ensure our I/O doesn't choke during the build process.

The Architecture of Trust

The concept is simple: Nobody touches the production shell. You push code to a repository, and the server pulls it, builds it, and swaps it live. No downtime. No human error.

To make this work, you need three things:

1. A Version Control System: Git (obviously). SVN is dead; let it go.
2. A Build/Trigger Mechanism: We will use a bare repository with post-receive hooks.
3. Iron-Clad Hosting: You cannot run this on cheap OpenVZ containers. The heavy I/O of a git checkout and build process will get your CPU stolen by noisy neighbors. You need dedicated resources.

This is why I deploy on CoolVDS. Their KVM virtualization guarantees that my RAM and CPU cycles are mine. Plus, their new SSD tiers (using enterprise-grade Flash) mean my disk writes don't hang when I'm compiling assets.

Step 1: The "Hub" Setup

We are going to create a "bare" git repository on your CoolVDS instance. This acts as the receiver for your code. Assume we are running Ubuntu 14.04 LTS.

# On your CoolVDS server (Production)
# Create a user for deployment to keep things secure
sudo adduser deploy
su - deploy

# Create the directory structure
mkdir -p ~/git/project.git
mkdir -p ~/www/project

# Initialize the bare repo
cd ~/git/project.git
git init --bare

Step 2: The Magic Hook

The post-receive hook is a shell script that runs after you successfully push code to the server. This is where the automation happens. We aren't just copying files; we are checking out a clean version of the code.

Create the file ~/git/project.git/hooks/post-receive:

#!/bin/bash
TARGET="/home/deploy/www/project"
GIT_DIR="/home/deploy/git/project.git"
BRANCH="master"

while read oldrev newrev ref
do
    # Only deploy if master branch is pushed
    if [[ $ref =~ .*/$BRANCH$ ]]; then
        echo "Master ref received. Deploying to Production..."
        git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
        
        # Run post-deployment tasks
        cd $TARGET
        # If you are using Composer (PHP)
        # composer install --no-dev --optimize-autoloader
        
        # Reload Nginx to clear cache (optional)
        # sudo service nginx reload
        
        echo "Deployment complete."
    else
        echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
done

Important: Make it executable.

chmod +x ~/git/project.git/hooks/post-receive

Pro Tip: Never run your web server as root. Ensure the deploy user has ownership of the web directory, and add your web user (usually www-data) to the deploy group with read permissions. This satisfies the security requirements of Datatilsynet regarding access control.

Step 3: Performance Tuning for High Load

Now that deployment is automated, let's talk about speed. When you automate, you deploy more often. This puts stress on your disk I/O. If you are on a spinning HDD, your site will slow down during a deployment. This is unacceptable.

On CoolVDS, we have access to high-performance SSD storage. I've benchmarked their storage subsystems, and they are pushing serious IOPS. To take advantage of this, you need to tune your Linux kernel to handle the throughput.

Edit your /etc/sysctl.conf to optimize for low latency network traffic (vital for Norwegian users connecting via mobile networks):

# /etc/sysctl.conf

# Increase system file descriptor limit
fs.file-max = 2097152

# Optimize TCP window for high-speed connections
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Protection against SYN floods (basic security)
net.ipv4.tcp_syncookies = 1

And for your database? If you are running MySQL 5.5 or 5.6 (which you should be), the default configuration is garbage. It is tuned for 512MB RAM servers from 2005. You are on a CoolVDS production instance; use the RAM!

# /etc/mysql/my.cnf

[mysqld]
# Set this to 70-80% of your total RAM
innodb_buffer_pool_size = 4G

# Essential for SSD performance
innodb_flush_method = O_DIRECT
innodb_io_capacity = 1000

The innodb_io_capacity setting is crucial here. Default is 200. With CoolVDS SSDs, you can safely bump this to 1000 or even 2000, allowing the database to write to disk much faster without locking tables.

Local Data Sovereignty

Working in the Norwegian market, we have to talk about data privacy. With the recent revelations about NSA surveillance (the Snowden leaks are still fresh in everyone's mind), keeping data within national borders is becoming a hard requirement for many CTOs.

By hosting on CoolVDS, your data stays here. You get low latency to Oslo and Bergen because you aren't routing through Frankfurt or London. But more importantly, you have a physical jurisdiction argument when the legal team asks about Safe Harbor compliance.

Why This Workflow Wins

I switched a client to this workflow last month. Their "time to deploy" went from 20 minutes (FTP upload + manual cache clear) to 4 seconds. That is the power of Git-driven infrastructure.

But software is only half the battle. You can have the best scripts in the world, but if your virtualization layer is oversold, your scripts will hang. I choose CoolVDS because they respect the hardware. They don't oversell RAM, and they give me the raw KVM power I need to run Jenkins, Git, and Nginx on the same box without melting the CPU.

Next Steps:
1. SSH into your server and check your git --version.
2. Benchmark your disk I/O with dd or ioping.
3. If you are seeing wait times over 10ms, it's time to migrate.

Don't let slow hardware kill your automation. Spin up a CoolVDS SSD instance today and start deploying like a professional.