Migration In Action

看過昇級的背景資訊後，可以真的動手了。

Plone 3.3.5 昇級到 4.0.x，算是相對容易的情境，原則上，把 Plone 3.3.5 選用或自製的模組版本，盡量先更新到合適的號碼，這樣就可以準備一份夠好的 Data.fs。再次提醒，實際昇級前，一定要把 Data.fs 備份好，完成昇級步驟後，還要進行許多測試工作，途中遇到錯誤的話，還是可能要用到 Data.fs 備份檔。

Plone 3.3.5 和 4.0.x 都有 buildout 工具，利用 buildout 就可以把許多昇級工作搞定，昇級 buildout.cfg 最簡單的方式，是先用 Unified Installer 安裝系統，再把 egg 和其他設定值搬到 buildout.cfg 裡。

依據上述的原則，下列是實戰過程的記錄。

舉例來說，原本 Plone 3.3.5 搭配 Ploneboard 2.0，先昇到 Ploneboard 2.2 之後，就可以同時在 Plone3 和 Plone4 使用。不過，Ploneboard 搭配的 python-dateutil，要使用 1.5 版本，處理方式是在 [versions] 設定區段，指定為 python-dateutil = 1.5，如果安裝 python-dateutil 2.0 的話，會造成 Ploneboard 無法執行，處理方法是刪掉 python-dateutil 2.0 再裝 1.5 版本。

webcouturier.dropdownmenu 模組也有類似的情況，它的 2.0 版本是搭配 Plone 3.x，到 2.1 版本就同時支援 Plone 3 和 4。另外，我是昇級 Plone4 後才發現 webcouturier 有 2.1 版，事後再昇級 webcouturier 並沒問題。

設定 Plone 4.0.5 的 buildout.cfg 時，記得把 Products.PloneHotfix 加上去，執行 bin/buildout 之後，把舊系統的 Data.fs 放到 var/filestorage 目錄，執行 bin/plonectl debug 來啟動新系統，總之，要等完成昇級測試後，再改用 bin/plonectl start。

進 ZMI 的昇級畫面後，先勾選 dry run 執行模擬，接著有一系列的昇級動作，其中的 plone.app.upgrade 在 v40/betas.py 檔案裡，定義了 convertToBlobs() 函式，會把 File 和 Image 轉存為 Blob 檔案，這個過程會把舊檔刪除，再建立新檔，如果舊站已存在許多 File 和 Image 的話，這個步驟會花很長的時間。

手邊一個 9.6G Data.fs 建立 6.5G blobstorage，最後 Data.fs 剩下 278.9M，因此，執行昇級前最好留有 Data.fs 一倍以上的硬碟空間。