Skip to content

Why use automated deployment?

Thursday, August 26, 2010

I was talking with a developer about their first rails project, the deadline of which was looming. After a quick walk-through of the code I started asking about process stuff — what are you using for tests? Are you using capistrano for deployment?

The answers were “I’d like to use tests at some point in the future” — danger! — and that no, he was deploying things manually up to a vps instance.

I said that whatever server admin task like deployment that I can automate and do from my own machine, I will. He asked, “why, are you not a server guy?”

So, I thought I’d jot down a snapshot of why I use capistrano (or chef recipes, with engine yard-ish clouds) for deployment, in case someone else is wondering.

Three main reasons: flow, safety, and process.

Flow

This one’s pretty simple. During the course of a development day, my screen-estate is taken up by an editor window, a browser, and the console. My console (iTerm) usually has several tabs open, typically three per project: a server, a prompt at the app’s root for doing git operations and kicking off tests, and one tab that’s tailing the cucumber or rspec logs.

If I want to deploy, I just drop into the console that’s already open, and run a simple command (“cap deploy”) and I’m done. It’s just part of the flow, and flow is everything.

If I have to deploy something manually, that involves: * opening a new tab * logging into the server * moving to to the app root * running commands like git pull, etc * possibly restarting mongrels * logging out and closing the tab

None of which is in the flow of developing. In other words, I have to switch modes from developer to sysadmin, and switching modes kills the flow.

Safety

This one’s simple also. Capistrano has a lovely command: “cap deploy:rollback”. If I deploy something that’s not ready for primetime, and satellites begin falling from their orbits or nuclear attack turtles start becoming sentient before they’re meant to, I can just kick off a rollback and I’m back to safety and fluffy bunnies. That’s because capistrano keeps several releases stored on the server, and switching to a previous codebase is as easy (mostly) as switching some symlinks.

In the manual world, it’s messier. I don’t like messy. Not with prematurely-sentient nuclear turtles out there.

Process

Anything I have to do manually is something I’m likely to either screw up or forget. That’s because I’m a forgetful screw-up, but it’s important to build self-protection into your process flow.

Aside from updating the codebase, deployments can typically involve migrating the db, updating symlinks, restarting search servers, notifying services such as hoptoad and newrelic, etc. Anything that has to be done each time you deploy can be built into a capistrano script, so you don’t have to think about it. What you don’t have to think about, you won’t forget to think about, and you won’t screw-up.

If the updated codebase depends on a migrated db, and you forget to run the migrations after deploying manually, well here come the sentient nuclear turtles. And they’re mad.

So, keep the world safe: automate your deployment.

Filed in capistrano, rails | Tagged , , , | Comments (0)

quick tip: bunder, rails 2.3.8, and rspec

Wednesday, July 28, 2010

I set up an app on 2.3.8 with bundler, and when trying to run the rspec tests got .../config/Gemfile not found (Bundler::GemfileNotFound)

which is odd.

I’d grabbed the code for config/intializers/preinitializer.rb from gembundler.com; to solve the issue I changed line 15 from

ENV["BUNDLE_GEMFILE"] = File.expand_path("../../Gemfile", _ FILE _)

to

ENV["BUNDLE_GEMFILE"] = File.expand_path(File.join(Rails.root,"Gemfile"), _ FILE _)

Hope that helps…

Filed in Uncategorized | | Comments (0)

quick tip: zsh and bundler

Thursday, July 1, 2010

I’m just starting to look at bundler — way ahead of the curve as usual.

I’m using zsh, and every time I ran a bundle command I’d get:

correct 'bundle' to .. [nyae]?

To turn off the autocorrect message, just add this to your .zshrc:

alias bundle='nocorrect bundle'

Filed in Uncategorized | | Comments (0)

upgrading hoptoad: uninitialized constant HoptoadNotifier::Catcher

Saturday, February 20, 2010

Dept. of Quick Tips Dept.: If you’re upgrading from an older plugin version of the hoptoad notifier to the 2.2 gem, and you see uninitialized constant HoptoadNotifier::Catcher when you try to script/generate hoptoad, go to application_controller and remove the line:

include HoptoadNotifier::Catcher

Then run script/generate hoptoad again and all should be well.

Oh, and if you can’t unpack the gem, try removing lib/tasks/hoptoad_notifier_tasks.rake (via here).

Filed in rails | Tagged | Comments (0)

skeleton rails app starter

Monday, February 1, 2010

I’ve found a few tools that I like to use on all new projects, mostly for the presentation and testing layers. Following the dictum that lazy is good (and I’m far too lazy to make sure that’s the correct usage of ‘dictum’), I’ve created a starter app that has all those tools in place, so I don’t have to do all the script/generating etc each time.

In case it helps you, you can find it at http://github.com/madcowley/rails_skeleton.

Suggestions welcome.

So far, the list includes:

Presentation

Testing

Javascript

In case you want to do it by hand, here’s how:

rails

rails rails_skeleton
cd rails_skeleton

haml

sudo gem install haml (if needed)
haml --rails .

in environment.rb:

config.gem 'haml-edge'

(for compass)

compass

sudo gem install compass
rake rails:template LOCATION=http://compass-style.org/rails/installer

add to layout header:

 = stylesheet_link_tag 'compiled/screen.css', :media => 'screen, projection'
 = stylesheet_link_tag 'compiled/print.css', :media => 'print'
 /[if lt IE 8]
   = stylesheet_link_tag 'compiled/ie.css', :media => 'screen, projection'

formtastic

config.gem ‘formtastic’ script/generate formtastic

jquery

= javascript_include_tag ‘http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js’

rspec

in environments/test.rb:

config.gem "rspec", :lib => false
config.gem "rspec-rails", :lib => false

script/generate rspec

cucumber

script/generate cucumber

or

script/generate cucumber --spork</http://github.com/madcowley/rails_skeleton>
Reblog this post [with Zemanta]
Filed in rails | Tagged , | Comments (0)

migrating a rails app from 2.x to 3.0

Sunday, January 17, 2010

I’m sitting here with @gavinstark at major coffee/sandwich chain playing with rails 3.0 for the railsbridge bugmash weekend.

Here’s what I had to do to get the omnominator app migrated to 3.0. Some (most) steps taken from Yehuda Katz’s post.

Check out rails source:

git clone git://github.com/rails/rails.git

Run rails update script

I forked a copy of the omninator code for this; from the root dir of the app:

 ruby /path/to/rails3/railties/bin/rails .

Note that I had to call that with ruby, as it wasn’t pre-set to be an executable ruby script.

I let that overwrite all the script/ files etc.

Note about config/environment

The config/environment.rb now basically just requires config/application.rb, and all the config statements in config/development.rb, etc are wrapped in an initializer block like:

 Myapp::Application.configure do
      config.cache_classes = false
      ...
 end

So, do that for each of your env-specific config files, and (I think) move the config code from environment.rb to application.rb.

config.gem

Gems are now handled in Gemfile, instead of using config.gem in environment.rb etc.

Update the gemfile

Again, from Yehuda’s post, copy this block to your new Gemfile:

 # Add to the top
 directory "/path/to/rails", :glob => "{*/,}*.gemspec"
 git "git://github.com/rails/arel.git"
 git "git://github.com/rails/rack.git"

and then from the root of the app run:

gem bundle

(note that you need to have the ‘bundler’ gem installed, so ‘sudo gem install bundler’ if you need to..)

I had to remove a couple of initializers:

  • Hoptoad notifier initializer fails, so I commented it out for now; I’ll update this post when I figure out the Hoptoad compatibility
  • new_rails_defaults, which was added in 2.x to ease migration, failed under 3.0; that makes sense ’cause it’s redundant now.

That was it. The omnominator is a one-controller basically two-view app, so I’m sure there are other upgrade issues for more complicated apps, but maybe this will get you started.

Filed in Uncategorized | | Comments (3)

Setting up a new development environment on OSX

Friday, January 1, 2010

I recently set up a new MacBook Pro for development. Here’s what I did, mostly as notes to myself for next time:

Basic rails environment

I mostly followed Robby Russell’s guide, here.

That got xcode, macports, ruby and rails, mongrel and postgres installed.

MySql

Most of my projects use MySql instead of postgres. I installed Mysql from the binary on the mysql site, not through macports. The download link is here. For a new MacBook, I used the x86-64 package. Also install the startup item, which is included in the package.

Installing the mysql gem requires some path trickery, since I didn’t install the macports version. I followed these instructions, which worked well:

 sudo gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

To get the databases copied over with minimal effort, I just copied the /usr/local/mysql/data dir from my old machine to the new one.

Git

Most of my projects are now on git. Following the githubs, I installed it via macports. I included subversion, for those that still use it:

  sudo port install git-core +svn

Also gitx, which I’ve come to like; installs with a dmg.

Gems

At this point, it’s time to get the gem dependencies for projects installed. You should be able to clone a project and do

sudo rake gems:install
sudo rake gems:install RAILS_ENV=test

to get them installed.

Nokogiri

Having installed gems using the above, the groovy nokogiri started complaining that it was built against 1.7.3 but was loaded with 1.7.6, or something. This post, which is the best-titled post ever, fixed it.

Computer name

Not strictly related to development, but a question that came up for me setting up the new machine: How do I give it a good name?

Other tools

After all of the above, you should have a working environment for coding and running rails apps. There are several other tools I’ve come to rely on; here’s a few:

  • Textmate
  • The adobe suite, especially photoshop
  • xScope, a fantastic layout toolbox
  • SequelPro, a mysql client. This is handy for accessing databases via ssh tunnels.
  • growl
  • Firefox, with pixel perfect, web developer toolbar, and firebug, found here
  • OmniWeb, OmniFocus, and OmniOutliner Pro, from the omni group
  • For irc, colloquy or lime chat
  • I use DevonThink Pro Office for a kind of brian trust, but not as deeply as I might;
  • For time tracking and invoices, Billings
  • Some kind of virtualization, for testing in windows and IE. I’ve been using parallels, but am trying VMWare Fusion. I’ve also heard good things about Sun’s VirtualBox.
  • Pathfinder for finder goodness
  • I’m using Jolly’s Fast VNC for accessing my old machine remotely, via ssh
  • And, stepping out of my dev hat, Movie Magic Screenwriter, iWork, and the fantastic Scrivener
Filed in Uncategorized | Tagged , , | Comments (0)

deploying php with capistrano

Thursday, June 12, 2008

Capistrano is to deployment what a spatula is to scrambled eggs. It’s mostly thought of as a rails tool, but it works for any code you need to export from a source-control repository to a server on a regular basis.

Php, for instance. I’ve got a rails site that uses an open-source php shopping cart (I know), and as part of a server move and overhaul of deployment processes, I set it up with cap.

Mostly, deploying something other than rails with cap is a matter of subtraction. First, capify your app; go to the root directory and type capify .

Then, you’ll need to create a config directory off of the root, and a deploy.rb inside of that.

Here’s basically what the deploy.rb should look like: set :application, "myapp" set :repository, "my_repository_url"

role :web, "my_server_name" #eg "myapp.com" or "123.456.789.10" role :app, "my_server_name" role :db, "my_server_name", :primary => true set :user, 'my_deployment_user' set :use_sudo, false

set :svn_username, 'my_svn_user' set :svn_password, 'my_svn_pwd' set :svn_repository_url, 'my_repository_url' set :checkout, 'export' set :deploy_via, :export set :deploy_to, "/path_to/#{application}" set :shared_dir, "shared" set :log, "#{shared_dir}/log" set :etc, "#{shared_dir}/etc"

namespace :deploy do task :restart do # no need to restart the app - it's php! end end

and that’s it. I’ve got a couple of duplicate lines in there, and if I were slightly less lazy I would have figured out which ones can be removed before I posted this. Alas, such is not the case.

You can then go to the root of the app and type cap deploy and it’ll deliver the latest version to the server.

By default cap tries to restart the server and/or mongrel after it updates the code. With php that’s not necessary; the recipe above just overwrites the default restart task. You could also just say cap update_code which wouldn’t try to restart the server, or some other probably better solution.

Filed in capistrano, php | Tagged , | Comments (1)

running rake from cron

Thursday, June 12, 2008

Quick tip, mostly for myself:

I’m moving a site to a new server. I’ve got several cron jobs set up to do things like delete caches, rotate logs, backup the db, etc. Most of the code for those tasks is written as rake tasks, so it’s nice, readable ruby code and included in the code repository for the project.

The tasks weren’t working on the new server. Here’s a few things I did to track down the problem, from http://www.linuxquestions.org/questions/bsd-17/crontab-test-550745/: ps ax | grep cron : yep, cron is running * * * * * /bin/echo “hello world” >> /mydir/crontest.txt as a cron task: yep, cron is running for my user * * * * * cd current_path && rake my_task > /mydir/crontest2.txt 2>&1 : that gave me the error message “rake: command not found.”

“rake mytask” was working from the command-line, but not from cron; I’m guessing cron doesn’t load up the same env stuff that my user does. So, I set up the cron task like so: 1 * * * * bash /var/www/vhosts/myapp/shared/scripts/myscript.sh

and myscript.sh looks like so:

cd /app_curr_dir /usr/local/bin/rake mytask

And that works like a charm. So if you need to do some maintenance tasks on a schedule, that’s one nice way to handle it.

Filed in Uncategorized | | Comments (1)

Non-profits in Second Life – Best Practices

Thursday, February 7, 2008

Come by the Nonprofit Commons in Second Life tomorrow for a presentation and discussion of a new paper on best practices for non-profits in the virtual world. More info here. You can read the paper here.

Filed in npsl, second life | | Comments (0)