升級到 Rails 3.1，專案所要做的前置準備工作

http://wp.xdite.net/?p=3137

 

利用 RVM 做出 3.0 與 3.1 的 gemset

3.0 與 3.1 會動到 rake 版本還有一些 gem 。如果你手上有 3.0 的多個 project 又要把某些 project 升上 3.1，光 gem install rails -v=3.1.0 就會讓你的 3.0 環境炸掉。請先幫你的專案環境上 RVM 然後做出兩套 gemset。

把平日專案提醒的 DEPRECATED WARNING 全數修掉

目前 3.0 的警告，在 3.1 是幾乎全數被棄用的。沒有把這些棄用 API 修完，會造成你的專案無法開啟。常見的有 rails/init.rb ，RAILS_ROOT，RAILS_DEFAULT_LOGGER 這一些棄用 API。這些 API 有可能散落在專案裡或者是相依的 Gem 之類，有些地方還蠻難找的，務必找到它並改掉它們。

把專案的 CSS 轉成 SCSS

Rails 3.1 支援 SCSS，甚至是大力推薦使用，建議使用 compass 先搭配 Rails 3.0 進行轉和動作，同時整理 CSS。使用 sass-convert 可以將 css 轉成 SCSS。

我們在專案升級前，就曾經進行了 SCSS 轉換並整理 CSS 的動作。好處相當多。光維護專案的 style 就變得省力許多。

統一 stylesheets 內 image 路徑的寫法

每個 RD 的寫法不一樣。有好幾種寫法

* /stylesheets/images/
* images/
* ./images/
* ../images/

但這其中有一些路徑寫法，在轉成 SCSS 和上 asset pipeline 時會有問題。我的作法是在轉 SCSS 時就進行一次修整，將寫法統一為 /stylesheets/images ，把亂放在 pubic/images/ 卻應該屬於 public/stylesheets/images/ 的圖歸位整理。

上 asset pipeline 時，只要把 /stylesheets/images 取代成 /assets/images 就做完了，非常輕鬆。

拿掉 SCSS 內 image-url 這個 helper ，一律使用 url

我在 asset_pipeline，precompile 會遇到的 hash 問題 ，有解釋過使用這個 helper 會造成不同機器的 hash 會不一致，有上 CDN 的話會導致 CSS 噴白。

使用 Jammit 壓縮檔案

在知道有 asset pipeline 之前，我們在 deploy 時就已經使用 Jammit 去壓縮打包我們的 asset 檔案。因為 Jammit 是用 asset.yml 去管控需要壓縮的檔案。所以我們在轉成 asset pipeline 的時候只需要做 copy / paste 再少許修改就做完了…。（ CSS 與 JS 有 放置順序問題，我們趁用 Jammit 壓檔案時就整理過了）。

而 Jammit 需要寫 preheat asset task，此時我們也把 deploy preheat asset 的最佳實踐順序測完了。所以也只是改個 task 名稱而已…

準備一台 staging 和兩台 production server

第一次測試，我們是拿一台 staging server 先 deploy rails31 branch，把 Rails 3.1 的 precompile 實踐都找出來。此時發現兩個重大問題：

1. git 必須放在 /usr/bin/git 。因為 compass 使用 git 版本當做版號，passenger 找不到 git 會直接爛掉
2. sprockets 壓縮 asset 必須要有 JavaScript runtime，因此至少要可以裝上 nodejs，而 deploy 用的帳號必須要能夠執行 nodejs

測完沒問題之後。因為我們的架構最前面是有一台 Load Balancer 的。先停掉一台正式 deploy Rails 3.1，保證正式服務還是不會受影響。然後在這台使用 Rails 3.1 的機器上測看看有沒有 asset 忘記 compile 或者是 asset 位置漏調整到引發的的 bug。修到沒問題之後再正式全面 deploy 到正式機器。