Stop Using FTP: The Battle-Hardened Guide to Git-Centric Deployments in 2013

It is 2013, and I still see developers dragging files via FileZilla to production servers. This needs to stop. If you are editing /etc/php5/fpm/pool.d/www.conf directly via SSH, you are not a systems administrator; you are a liability. I have seen production databases corrupted and e-commerce stores vanish from the internet because of a single fat-fingered typo in a live config file.

The industry is shifting. We are moving toward a workflow where Git is the single source of truth. Your infrastructure state should mirror your repository state. If it's not in Git, it shouldn't exist on the server. This is the only way to scale without losing your mind, especially when managing high-availability clusters across European data centers.

In this guide, I will walk you through a "Git-Centric" workflow—what some forward-thinkers are calling Infrastructure as Code. We will use tools that actually work: Git hooks, Capistrano, Jenkins, and Puppet, all running on CoolVDS KVM instances.

The Architecture of Trust

Why does this matter? Because latency and consistency. If your server is in Oslo (connected via NIX) and your dev team is in Berlin, manual changes are slow and error-prone. By pushing code to a central Git repository which then triggers a deployment, you ensure that every server gets the exact same code, permissions, and configuration.

Furthermore, relying on shared hosting or OpenVZ containers for this level of automation is risky. OpenVZ kernels are shared; if a neighbor spikes their load, your Jenkins build hangs. This is why CoolVDS standardized on KVM (Kernel-based Virtual Machine) virtualization. You get a dedicated kernel and reserved RAM, ensuring your automated pipelines run predictably, every single time.

1. The Poor Man's Deployment: Git Hooks

If you don't have the budget for a dedicated Jenkins box, you can still automate. The bare minimum requirement is a post-receive hook. This script lives on your remote VPS and runs immediately after you push code.

Scenario: You want to deploy a PHP application to /var/www/html when you push to the production branch.

#!/bin/bash
# /var/git/project.git/hooks/post-receive

TARGET="/var/www/html"
GIT_DIR="/var/git/project.git"
BRANCH="production"

while read oldrev newrev ref
do
    # Only deploy if the master branch is pushed
    if [[ $ref =~ .*/$BRANCH$ ]]; then
        echo "Deploying ${BRANCH} branch to production..."
        
        # Create a temporary work tree
        git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f $BRANCH
        
        # Correct permissions
        chown -R www-data:www-data $TARGET
        
        # Reload PHP5-FPM to clear opcode cache
        service php5-fpm reload
        
        echo "Deployment complete."
    fi
done

Make sure to `chmod +x` this file. Now, a `git push live production` deploys your code instantly. No FTP client required.

2. The Professional Workflow: Capistrano & Puppet

Scripts are fine for blogs, but for a high-traffic Magento store or a complex Rails app, you need transactional deployments. Capistrano is the standard here. It allows you to keep multiple releases on the server and symlink the `current` version. If a deploy breaks something, you can rollback instantly.

Capistrano `deploy.rb` Configuration

Here is a battle-tested `deploy.rb` for a Rails app hosted on a CoolVDS NVMe-backed instance. Note the use of `deploy_to` and strict user management.

# config/deploy.rb
set :application, "coolvds_store"
set :repository,  "git@github.com:coolvds/store.git"

set :scm, :git
set :branch, "master"
set :deploy_via, :remote_cache

# User details
set :user, "deployer"
set :use_sudo, false
set :deploy_to, "/opt/apps/#{application}"

# VPS Norway Server IP
role :web, "192.168.1.10"                          
role :app, "192.168.1.10"                          
role :db,  "192.168.1.10", :primary => true        

# Maintenance tasks
after "deploy:restart", "deploy:cleanup"

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
end

This script handles the complexity of cloning, symlinking, and restarting the application server (like Passenger or Unicorn). Because CoolVDS provides full root access via KVM, you can install the necessary Ruby dependencies (RVM/rbenv) without hitting the limits often found on budget VPS providers.

3. Managing Configuration with Puppet

Code is one thing, but what about the server configuration? If you lose your server, how fast can you rebuild it? If the answer is "I don't know," you are non-compliant with basic business continuity standards (and arguably the Norwegian Personal Data Act regarding data availability).

Use Puppet to define your server state. Here is a manifest that ensures your web server is always installed and running with optimized settings.

# manifests/web.pp

package { 'nginx':
  ensure => installed,
}

service { 'nginx':
  ensure  => running,
  enable  => true,
  require => Package['nginx'],
}

file { '/etc/nginx/nginx.conf':
  ensure  => present,
  owner   => 'root',
  group   => 'root',
  mode    => '0644',
  source  => 'puppet:///modules/nginx/nginx.conf',
  notify  => Service['nginx'],
}

# Ensure specific virtual host is present
file { '/etc/nginx/sites-enabled/coolvds_app':
  ensure  => link,
  target  => '/etc/nginx/sites-available/coolvds_app',
  require => Package['nginx'],
  notify  => Service['nginx'],
}

Optimizing the Stack for Speed

Automated deployment is useless if the server itself is sluggish. In 2013, the bottleneck is almost always Disk I/O. While many hosting providers in Norway are still spinning 7.2k RPM SAS drives, CoolVDS offers SSD storage options that drastically reduce iowait.

However, you must tune your software to leverage this. A default MySQL 5.5 installation is configured for 512MB of RAM, which is pathetic for a modern VPS.

Optimize your `my.cnf`:

[mysqld]
# InnoDB Settings for 4GB RAM VPS
innodb_buffer_pool_size = 2G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2 # Speed over strict ACID compliance for non-financial apps
innodb_flush_method = O_DIRECT

# Connection Settings
max_connections = 300
wait_timeout = 600

Pro Tip: Setting `innodb_flush_method = O_DIRECT` on Linux prevents double buffering between the OS cache and database cache. On a CoolVDS KVM instance, this directly translates to lower memory overhead and faster query execution.

Compliance and Data Sovereignty

We operate in a strict regulatory environment. The Norwegian Data Protection Authority (Datatilsynet) takes the Personal Data Act seriously. When you automate deployments, you must ensure that customer data (logs, database dumps) never leaves the designated jurisdiction unintentionally.

By hosting on CoolVDS, your data resides physically in Norway (or strict EU jurisdictions), ensuring compliance. When you script your backups using `mysqldump` and `rsync`, ensure the destination target is also within the country. Do not blindly push backups to an American S3 bucket without verifying Safe Harbor status.

The Verdict

Manual server management is a relic of the past decade. The future belongs to those who script, automate, and version control their entire infrastructure. Whether you call it "DevOps" or just "doing your job right," the tools—Git, Jenkins, Puppet—are ready.

You need a platform that respects this workflow. You need raw compute power, consistent I/O performance, and the freedom of a true KVM hypervisor. Stop fighting with noisy neighbors and laggy connections.

Ready to professionalize your workflow? Spin up a CoolVDS High-Performance KVM instance today and push your first commit to production in under 60 seconds.