Stop Using FTP: Building Atomic Deployment Pipelines with Jenkins and KVM in 2014

It is 3:00 AM on a Friday. You just dragged a modified class.php file via FileZilla to your production server. The upload stalled halfway through. Now your site is throwing a 500 Internal Server Error, your client is calling, and you are sweating. If this scenario sounds familiar, you are doing it wrong.

In 2014, "it works on my machine" is no longer a valid excuse. The industry is moving toward Continuous Integration and Continuous Deployment (CI/CD). We aren't just writing code anymore; we are engineering the factory that builds the code. But here is the hard truth: you cannot build a robust pipeline on cheap, oversold shared hosting or unstable container-based VPSs.

I’ve spent the last month migrating a high-traffic e-commerce platform from a manual deployment mess to a fully automated pipeline. The difference isn't just speed; it's sanity. In this guide, I’m going to walk you through setting up a "Capistrano-style" atomic deployment using Jenkins and Bash, and explain why we migrated everything to CoolVDS KVM instances to handle the load.

The Architecture of an Atomic Deploy

The goal is simple: the web server should never serve a broken or half-uploaded file. We achieve this by using symlinks. We deploy the new code to a separate directory, run our build steps (composer install, minification), and only when everything is green do we switch the symlink. It’s instantaneous.

The Directory Structure

Forget the standard /var/www/html root. We need structure. On our servers, we use:

/var/www/project/
├── releases/
│   ├── 20140528100001/
│   ├── 20140528113045/
│   └── 20140528142000/
├── shared/
│   ├── uploads/
│   └── config.php
└── current -> /var/www/project/releases/20140528142000/

The Engine: Jenkins CI

We use Jenkins. It's ugly, it's Java, and it eats RAM like crazy, but it is the undisputed king of flexibility. Travis CI is nice for open source, but for private business logic where you need total control over the environment, a self-hosted Jenkins instance is mandatory.

Pro Tip: Do not run Jenkins on the same server as your production web server. Jenkins builds can spike CPU usage to 100%, causing your web application to hang. We run a dedicated "Build Node" on a CoolVDS Micro instance, which pushes artifacts to the Production Node. Isolation is key.

The Deployment Script

You don't need complex Ruby gems if you know Bash. Here is the exact shell script we use in our Jenkins "Execute Shell" build step. It utilizes rsync and SSH keys for secure transport.

#!/bin/bash
# CI Deployment Script v1.2

# Configuration
USER="deploy"
HOST="192.0.2.10" # Your CoolVDS IP
DIR="/var/www/myapp"
DATE=$(date +%Y%m%d%H%M%S)

# 1. Prepare the artifact locally (Minify JS/CSS, Install Vendors)
echo "Building artifact..."
composer install --no-dev --optimize-autoloader

# 2. Transfer to server (Excluding .git to save bandwidth)
echo "Deploying to $HOST..."
ssh $USER@$HOST "mkdir -p $DIR/releases/$DATE"
rsync -azP --exclude '.git' . $USER@$HOST:$DIR/releases/$DATE/

# 3. Link Shared Resources (Config, Logs, Uploads)
ssh $USER@$HOST <

server {
    listen 80;
    server_name www.cool-client-site.no;
    
    # Point to the symlink, not a specific release folder
    root /var/www/myapp/current/public;
    index index.php index.html;

    # Disable logs for static assets to save I/O
    location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
        access_log off;
        expires max;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}