Subversion Deployment: DGEDeploy v2 and DGEPush

Wednesday, September 17, 2008

Back in February I released a Ruby script called DGEDeploy . We use DGEDeploy internally at Donat Group to help manage several of our project deployments.

Besides being a misnomer, DGEDeploy had one major weak spot: actually pushing code to servers. That, and a few other bugs, are fixed now in this latest release. Heck, lets call it version 2.

The latest version adds a new script, DGEPush, that acts as a simple RSync front-end. When using SSH keys it’s a breeze to merge a development branch into staging and push to the server.

DGEPush features list: * Rsync’s code using the -C option to skip .svn and CVS directories. This saves server space, and is a better security practice. * Can use SSH keys for better security and ease of use. * Can deploy to multiple servers in one shot.

Here’s how you get it running:

Create a dgepush user, on your remote server

On Ubuntu / Debian this is as simple as:

# Log into your remote server
ssh remote-server.com

# Create an account called 'dgepush'
sudo adduser dgepush

If you like, set up key based password-less logins for the remote user:

# On 'local' machine, ie: your laptop
sudo adduser dgepush
sudo su dgepush
cd ~

# Create the SSH keys
mkdir -m 700 .ssh
cd .ssh
ssh-keygen -t rsa -f dgepush-key
# !! Don't enter a passphrase, just hit Enter and Enter.

# Copy the key to the remote machine, this syntax only works on Linux.
# Possibly only on Debian / Ubuntu Linux.
ssh-copy-id -i ~/.ssh/dgepush-key.pub dgepush@remote-server.com

Test your SSH keys ssh -i /home/dgepush/.ssh/dgepush-key dgepush@remote-server.com should log right in without a password.

Here’s some other tutorials on the subject: * Password-less logins with OpenSSH * ssh-keygen: password-less SSH login

Update your dgedeploy-projects.conf

Adding a ‘servers’ section to any workflow enables you to get started with DGEPush.

/etc/dgedeploy/dgedeploy-projects.conf

# YAML 1.1
# Settings for example-project deployment
example-project:
  # The workflow field is required, the order of the parameters specify which
  # branch merges with which branch.  eg:
  #     development --> staging --> live
  workflow:
    - development
    - staging
    - live
  development:
    # The order of the urls parameter is important.  The first in the list will
    # be used as the default choice whenever necessary.  Each url should be,
    # a directory inside a Subversion repository, of course.  All urls should
    # be in the SAME Subversion repository.
    urls:
      - http://example.com/svn/example-project/trunk
  staging:
    urls:
      - http://example.com/svn/example-project/tags/staging
    servers:
      # This server uses key based password-less logins.
      - "-e 'ssh -i /home/dgepush/.ssh/dgepush-key' dgepush@stage.com:/var/www/stage.com/"
      # You can push to multiple servers by adding more lines!
      - "dgepush@mirror-stage.com:/var/www/mirror-stage.com/"
  live:
    urls:
      - http://example.com/svn/example-project/tags/live
    servers:
    # This server will require a password every time DGEPush is run.
    - "dgepush@live.com:/var/www/live.com/"

DGEPush in action

If you have already got DGEDeploy up and running using DGEPush is one more step. Here’s a basic example:

# First merge trunk into staging branch
sudo dgedeploy example-project http://example.com/svn/example-project/trunk
# Next push the staging branch to the server
sudo -u dgepush  dgepush example-project staging

Important points: * sudo -u dgepush runs the command as the dgepush user * dgepush example-project staging copies the contents of the dgedeploy cace for ‘example-project/staging’ to remote server. In other words, DGEPush won’t work unless you have initialized your project with DGEDeploy at least once.

file attachment Download DGEDeploy-v2.0.tar.gz

new comment