articles tagged with subversion

Part 2. Setup Capistrano on the Rails app and run a test deploy to your server

1 comment

Starting Point

  • You have got your Rails app under version control with SVN as described in the first tutorial
  • First make sure you have Capistrano installed, you can get it as a free Ruby gem with;
    gem install capistrano
  • ‘Apply’ capistrano to your Rails app on the dev box, this creates some config files locally for Capistrano deployment to work.
    cap --apply-to /u/apps/sitename.com sitename.com
  • Edit the Capistrano’s deploy configuration in /u/apps/sitename.com/config/deploy.rb to set the correct roles for your server;
    set :repository, "svn+ssh://matt@dagobah/svn/#{application}"
    role :web, "server"
    role :app, "server"
    role :db,  "server"
    set :deploy_to, "/u/apps/#{application}"
    
  • From within the Rails directory (/u/apps/sitename.com) run the rake ‘setup’ task to remotely setup Capistrano’s directories on your server;
    rake remote:exec ACTION=setup
  • Try a test deploy to the server (may ask for password during sudo) this will;
    • Checkout the latest revision of your application from your remote repository to the /u/apps/sitename.com/releases directory on your server
    • Update (or create) the /u/apps/sitename.com/current symlink so it points to this new revision
      rake deploy
  • If all goes well, your Rails app should be checked out under /u/apps/sitename.com/current on your remote server. Run ‘rake deploy’ again if you like and see what happens. A new ‘release’ will be checked out to /u/apps/sitename.com/releases/timestamp/ and the symlink at /u/apps/sitename.com/current will be automatically setup to point to it.

Capistrano Tips

  • Obviously with lots of deploys, you’ll start getting loads of release directories on your server, all containing your entire Rails app. You can run the ‘cleanup’ command to remove older releases. In config/deploy.rb – set the following to say how many releases you’d like to keep after a cleanup
    set :keep_releases, 3
  • Then in the Rails directory run;
    cap cleanup

So there you have it, you can now deploy using Capistrano to your server from your dev box and your Rails app is safely under SVN version control. There is loads more you can do with Capistrano (see the links below)

In the next part of this guide, I’ll go through building the hosting stack (lighttpd/pound/mongrel) on your server. And making use of Capistrano to help with deploying your versioned Rails app around an unversioned folder containing the mints/ stats package (which we’ll also get running under PHP with lighttpd)

References

Part 1. Setting up SVN on a working Typo build (or any Rails app)

no comments yet, post one now

So in this post its all about getting your existing Typo (or rails app) under version control with SVN.

Starting Point

  • Have a rails site working and using lighttpd on your local dev box under /u/apps/sitename.com
  • Your remote server has SVN installed (try svn -v) and Rails/Lighttpd installed
  • Make sure you have an ssh key setup for accessing your server from your dev box
  • If you will have multiple users checking in and out and using Capistrano/SVN – set them all up a with ssh keys and create a new ‘developer’ group on the server (that has permissions on svn repository folders and /u/apps/)
  • Note: if you make a mistake, you can use this command to clean away all svn folders from the CWD downwards
    find . -type d -name '.svn' -print0 | xargs -0 rm -rdf 

Create SVN repository on svn server, checkin all rails code, then check out a working copy again

  • Login to the server and create a top level directory svn to hold your repositories;
    mkdir /svn
  • Create a new repository in it with;
    svnadmin create /svn/sitename.com
  • On your dev box, import the entire rails app to this new repository on ‘server’ with a simple comment;
    svn import -m "initial import" /u/apps/sitename.com svn+ssh://matt@server/svn/sitename.com
  • On dev box, rename /u/apps/sitename.com to sitename.com.stepaside – you could delete it before checking out your working copy, but its safer to do this in case anything goes wrong.
    mv /u/apps/sitename.com /u/apps/sitename.com.stepaside
  • Now checkout from the new svn repository to your dev box with;
    svn co svn+ssh://matt@server/svn/sitename.com /u/apps/sitename.com/
  • If all is ok, you can now delete sitename.com.stepaside
    rm -r /u/apps/sitename.com.stepaside

SVN Tips

  • You can run svn update, to update your current working copy with the latest from the server repository;
    svn update /u/apps/sitename.com
  • You can run svn commit -m “comment” to commit all changes from your working copy to the repository on the server
    svn commit -m "your comment" /u/apps/sitename.com
  • You can run svn status to see what files have changed or are not under version control;
    svn status /u/apps/sitename.com
  • You can add files/folders to svn’s ignore list for a particular file under version control using propedit; e.g. to set whats to be ignored in the config/ folder;
    svn propedit svn:ignore config/
  • This will popup a text editor (usually vim) – allowing you to specify files/folders inside config/ to ignore – e.g. .rb or deploy etc. In vim, press I to start editing (inserting), edit the file and press Esc and ‘ZZ’ to save and exit. (easy!) – Of course for these ignores to take place you’ll have to do an svn commit.
  • IMPORTANT for these ignores to work on files/folders that are already under SVN version control, you’ll first have to un-version and delete them; So back up the file/folder first then SVN remove it with;
    svn remove /path/to/file
  • Then place the backed up file/folder into your working copy again (if its a folder, delete any .svn folders in it) (Its a real pain, but ‘svn status’ is your friend during this process)
  • You can run svn status —no-ignore to see what files you’ve added to svn’s ignore list (these don’t get version controlled
    svn status --no-ignore /u/apps/sitename.com

References

Intro. All kinds of 'newness'

1 comment

So here we are, your looking at a fresh new install of Typo 4.0, with my custom theme, migrated blog content and mint stats running on a new VPS host, all served up on a platter with a new hosting stack (Lighttpd/Pound/Mongrel) – So basically, all kinds of ‘newness’.

As I mentioned – in the next couple of posts, ill try to walk through what it took to set this up. There are lots of guides already out there that take you through parts of this process, but I am attempting to gather my entire experience together and apply it to an existing Rails application (this Typo blog) – Working with a real Rails app like this, you come across ‘gotchas’ that you wouldnt normally see with a fresh vanilla Rails.

I have taken to using a blank page on my wiki scratchpad to log what I do, when I do it. What you get below is basically a cut & paste from there. Im working with a Mac/OSX as my local development machine and a Debian Rimuhost VPS as my server. Im assuming you have root access on both boxes to do this. And while you could do all this with Windows – I choose not to (I’ve been down that road before)

Terms Used

  • server (production/svn server) – the remote box hosting the svn repository and live website, and its alias on your local dev box
  • dev box – local client machine contains working copy of site
  • sitename.com – domain name of site
  • CWD – abbreviation for current working directory
  • Rails directory – the top level Rails dir, i.e. the one containing app/ config/ public/ etc.
  • start reading PART 1
← (k) prev | next (j) →