Harnessing Capistrano

Harnessing Capistrano - RailsConf2007 Tutorial
Jamis Buck

Slide aand demos available here.

Started out as a Deployment tool

Can also use it for:
+ monitoring tool across all servers (ps, df, uname, etc.)
+ server maintenance (mounts, symlinks, ...)
+ troubleshooting

A basic config file and a demo.

A config using a gateway and a demo.

A cool description and demo of 'cap -e shell' which creates and caches a connection to each deployment server. Can be scoped by role or host.

Cap 2.0 adds namespaces for tasks. Sort of a way of grouping like tasks. (eg. cap tail:showuploadlog groups the showuploadlog task into the tail namespace.

Can do variables.

And transactions, so you can make sure tasks complete on all servers or it rolls them all back - no inbetween. No good way to recover if a rollback fails.

All sort of options for including other cap files. This was always optional in Cap 1.x, but there is no default config in Cap2.0.

You can also script-check dependencies (cap deploy:check). That looks damn useful.

scrpit/spin tell cap how to start your application Many times i's script/process/spawner

cap deploy:cold <- first time deploy

cap deploy:rollback
cap deploy:migrations
cap deploy:web:disable
cap deploy:web:enable
cap deploy:cleanup <- clean up all but the last 5 releases

In addion to standard a version control-based checkout, you can do other types: export, copy, remote cache, or you can roll your own. (Set by :deploy_via option.)

There are all sorts of nifty options to get Cap to work with all sorts of version control systems.

Lots of helpers: run, sudo, stream, connect, find_task, etc.

In the ways of advanced usage, there are:
+ before_ and after_ events (before_deploy: run_tests)
+ custom callbacks: (email notifications, etc.) with complex rules
+ staging environments: you can script deploys to behave differently based on target

JRuby on Rails Tutorial

JRuby on Rails - RailsConf 2007 Tutorial

Advantages:
Take advantages of existing Java libraries
Run on Java infrastructure
Supports Java's multibyte/unicode strings.
Support Ruby's thread API, one native thread = one system thread, good multicore use.
True concurrent threading.

Great progress in the past year. From barely running rails 1.1 last year to running all of rails (except some lowlow demand dark corners) now, with good performance on everything but RDoc.

Most Gems just work. Anything pure Ruby (or with a JRuby port) runs.
Webrick works.
JRuby port of Mongrel works.

Differences:
1-Database support
Pure Ruby drivers work - mySQL
All the JDBC drivers you'd want to use work. (Yay!) (Some need custom coding to support migrations.
JDNI for connection pooling (More yay!)

2-No Native Extensions
Unless there's a port.
Mongrel - done
Hpricot - done
Database support - some done, some in progress
RMagick - in progress

3-Command-line Performance
Very good (possibly faster) once you're running, but typical java-slow startup performance.

Deployment
1. Mongrel works well. No process forking, process management
But why? Use Java App Servers via GoldSpike (or rails-integration) plugin.
2. Build WAR files for Rails apps.
One plugin, pure Ruby, out comes a deployable WAR file.
3. Glassfish server gem. (Sort of a "Pack" in the box implementation.)
Not yet. But soon.

Migrating existing Rails apps to JRuby/Rails
Be aware of the currently unsupported features.
1. Database support
- MySQL is great
- Derby & HSQL work well. Small embedable DB.
- Postgres - Few out of 1000+ tests.
- Oracle - starting to get attention
- MS SQL Server & DB - Need help, haven't really been worked on much.
Migrations mostly work well, tricky on some DBs that don't have all features.
Fixtures work well, parts of rails test. Issues generally YAML rather than DB issues.
2. Native Extentions
Option 1 - Use something else, aka don't do it.
Option 2 - Use an equivalent Java library. (binds you to jruby)
Option 3 - Port the library yourself.
Option 4 - Port by wrapping a java library.
3. Deployment Options
- Mongrel: works, but not the most efficient
- Existing WebApp Server: good concurrency, clustering, resource pooling
- Grizzly/GlassFish v3 option: lightweight, gem mongrel-like install