Requiring SSL Using Route Constraints in Rails 3

The new router in Rails 3 makes it super easy to require SSL for certain routes. Just use the following in your config/routes.rb:

MyApp::Application.routes.draw do
  class SslConstraint
    def self.matches?(request)
      request.ssl?
    end
  end

  scope :constraints => SslConstraint do
    resources :payments
    # Other SSL routes go in here
  end
end

Now, this is a pretty simple example–you’ll likely want to also have routes to redirect if a user tries to access without SSL, but it definitely shows off the power of the new router.

Posted on August 13, 2010 • 2 Comments
Tagged with: Ruby on Rails, Rails 3, Development, SSL

Easy Deploys to Multiple Environments with Capistrano

At Viddler, we’re switching to using Git and Capistrano for our internal projects, and I was tasked with setting up the system to deploy our code to both staging and production environments. Capistrano doesn’t have built-in environment switching, but it’s dead simple to add it yourself.

The key to getting this to work is to utilize Capistrano’s ability to chain tasks–if you run cap task1 task2, it will run the two commands in the order you listed them. Variables are shared between the tasks, so if you set a variable in task1, task2 will be able to access it. To get multiple environments working, you just create tasks to set environment variables, which you call before the actual task you want to run.

The first step is to figure out which variables you need to change, and then move them into their own tasks. Here’s an example of the tasks we added:

desc "Run on staging server"
task :staging do
  server "staging.myserver.com", :app, :web, :db, :primary => true
end

desc "Run on production server"
task :production do
  server "myserver.com", :app, :web, :db, :primary => true
end

Now, if you want to deploy to staging, just run cap staging deploy, and for production run cap production deploy. Easy.

Posted on December 10, 2009 • Leave a Comment
Tagged with: Capistrano, Viddler, Tips, Development, Code

The Perfect Git Workflow for a One Person Project

A few months ago, I started investigating Git, and I fell in love with how much easier it made managing my code. I’m managing the source code to this site with Git, and along the way I’ve come up with a pretty good workflow for myself. The basic steps are:

1. Branch
2. Commit
3. Rebase
4. Merge
5. Deploy

Let’s go through each one to see how it all works together.

Branch

With SVN, I found myself hating branching–it was always a complicated procedure, and I could never remember how to do it. In Git it’s as easy as git checkout -b <branch-name>, and you’re ready to go. Once you have a branch, you can modify it however you want, and you don’t have to worry about interfering with the master branch. In order to keep your master branch bug free, commit only to branches, not to master itself.

In addition to creating new branches for major features, I always have a few branches around that I pop into for certain things:

• “design” - any changes I want to make to the design go here
• “optimize” - optimizations to the site
• “bugfixes” - a place to work on minor bugfixes

Having these branches allows me to make small fixes to the site, and if it turns out it’s more than just a small fix, it doesn’t interfere with anything else.

Commit

In the Subversion world, it’s a pretty common practice to make very large commits, consisting of many changes. With Git, you should constantly be committing. By making many commits, you make it easier to find bugs you may have introduced, and it makes it a lot easier to track your progress. If you don’t like the thought of wading through long lists of commits in your logs, don’t worry–before bringing it over to the master branch, you can consolidate things with interactive rebasing, but while you’re hacking away on a branch, it really is advantageous to have many small commits.

Rebase

Rebasing is one of the harder things to grasp when you’re first learning about Git. For in-depth coverage of the topic, check out the Rebasing page in the Git Community Book. In a nutshell, doing git rebase master takes any commits to master and inserts them into your current branch, so you can then make sure your new code still works, and it’s a lot less hazardous than doing a merge. Rebasing your branch before putting into master is really important because it allows you to deal with any merge issues before the code goes to your main branch. To rebase, just run git rebase master.

Merge

After rebasing the branch, it’s safe to merge it into master. Since I’ve already dealt with any merge issues with the previous step, it’s as simple as checking out the master branch and running git merge <branch-name>

Deploy

I use Capistrano to deploy my code, so I’m constantly typing git push followed by cap deploy to deploy changes to my server. To make it easier, I just put both commands into one git alias:

deploy = !git push && cap deploy

Now I just need to run git deploy and it automatically pushes all of my changes to the remote Git repository and then deploys the site using Capistrano. Here’s some more information about Git aliases.

Useful tools

Though I primarily use Git through the command line, I really like using GitX to visualize branches. To host my repositories on my server, I use Gitosis, though if I had a few more projects, I’d dole out the money for a paid account at GitHub.

Have a great Git workflow? Think mine’s terrible? Let me know in the comments!

Posted on July 30, 2009 • 5 Comments
Tagged with: Git, Source Control, How To, Tips, Development