從遺留技術棧升級里，我學到的八件事
幾周前，當我使用 Mifa 主題刷新我的博客時，我發現了一件不得了的事情：我的博客使用的 Python 版本是 2.7，而不是我預期的 3.5。並且我用的 Django 版本是 1.9，它是 2015 年的版本。這些讓我意識到，如果我再不做點什麼，我的博客可能就維護不了了。
畢竟 Django 已經 2.0 了，而 Python 2.7 即將（好多年了）成為過去式了。
儘管我在之前的文章，講述了一系列的遺留系統的問題，其中之一就是遺留技術棧。因為技術棧老舊而導致系統難以維護，並不是我們想要的結果，只是當它並不是我們的第一優先順序事務時，短期的技術棧老舊也是可以接受的。
於是，我決定要去升級我的博客的技術棧了，理想中的步驟很簡單：
只是在這個過程中，遇到一系列的坑。真實的步驟如下所示：
接著，讓我來一步步複述這個過程。
1. 創建全新的環境
如上一篇文章《薦書《遺留系統：重建實戰》：當你面對一坨代碼時，你應該這麼做 所說，我們應該對環境搭建這個任務進行計時，以便於找出系統的瓶頸。
首先，我遇到的第一個問題是：MBP 上沒有環境。因為之前筆記本的硬碟壞了，上面的大部分資料都丟失了，因此我需要從頭搭建一個環境。
對於我而言，這是一次相當不錯的機會，它可以驗證系統的本地配置是不是正確的。然後，我發現新的系統上也沒有安裝 virtualenv，於是不得不重從搭建一個環境。
然後，我按照我在博客源碼上的 README，發現並沒有搭建成功。這種感覺就像你拿著一本產品說明書，發現上面說的都是錯的一樣。
簡單的總結一下這個階段的幾個原因：
當然還有其它一些問題，讓我再細細說來。
2. 使用線上的數據進行測試及資料庫遷移
在我早期的項目中，我們一般會擁有一份半年前的線上環境，用於在 staging（模擬環境）環境上進行測試。它可以用數據證明，這些功能本身是相當可靠的。
搭建環境的過程中，我嘗試創建一個全新的測試資料庫。但是，想一想發現這樣做容易出現問題，於是便想找份線上的環境的資料庫進行測試。雖然我並沒有將我的各種環境充分的自動化，但是我會定期手動將資料庫（SQLite3）備份到 AWS S3 上——我最初選擇使用 SQLite3 的主要原因是，備份方便，不需要佔用額外的伺服器資源。對於一般的應用來說，使用 MySQL/MariaDB 才是正確的選擇。SQLite 3 是我在博客設計初期做的一個錯誤的決策，當時 Too Young。未來，可能會將資料庫切換到 DynamoDB 上。
再回到線上數據的這一問題上，除了應對數據本身的變化之外。還有一點是，Django 或者 Mezzanine 在升級的時候，都需要進行資料庫遷移。
我之前將 Mezzanine 1.3 升級到 Mezzanine 3.0 的過程中，遇到一系列的資料庫問題，最後不得不重建資料庫。這個慘痛的經歷告訴了我，資料庫遷移是一個大坑。
3. 更細力度的版本管理控制，方便回滾
是的，即使你更新了個小依賴，也要確保使用了版本管理。它可以讓我們隨時能回滾到上一次個性，以確保遷移的正常。
升級 Django
如果你在某一時刻，你同時更新了 A、B、C 依賴，那麼可能因此修改大量的代碼。而在修改代碼的過程中，一旦出錯的話，那麼回滾的難度就變得相當的大。
於是我提交的步伐，比以往的正常時候都更小了。小到只更新一行配置，我也會做一個提交。
反正最後是遷移成功了，不能證明這個策略是不是對的。但是，這樣做是對的。
4. 優先升級次要組件的版本，以方便向上兼容性
對於項目中用到的一些輔助軟體，如使用 作為 RESTful API 框架，我優先升級了它們。對於這些框架而言，他們在兼容低版本的同時，也會兼容更版本的軟體。但是高版本的 Django，有可能並不會兼容低版本的其它軟體。因此，優先升級這些組件，可以保證核心組件可以更容易遷移。而不是在升級核心框架的同時，查看是否有這些次要組件帶來的問題。
過去我一般不會採用固定依賴版本的方式來運行部署，如 Ruby 中的 Gemfile，Node.js 中的 Yarn.lock，Python 中採用的方式是：
如上所見，我只會在重要的組件中，採用 fix 的版本號，主要是為了方便升級。對於次要組件來主，這種策略相當的成功。
5. 一步步升級核心框架
好了，現在到了最大的坑裡，升級 Django 版本。
事實證明，直接對著 CHANGELOG 來修改代碼，是最簡單的一種升級方式。
起先我直接改 Django 改成了 2.0.1 版本，發現一系列的不兼容——主要是 Mezzanine CMS 引起的問題，於是只能轉到 1.10.7。
然而，從 1.9.6 到 1.10.7 算是一個大的升級，為 2.0 移除了一系列不兼容的 API，如：
在遷移的過程中，還發現了一個第三方組件不支持新版本的 Django。
6. 必要時，自己編寫組件代碼
使用開源軟體，便意味著：在你使用的過程中，作者有可能隨時會棄坑；因此，隨時要做好填坑的準備。在我遷移的過程中，也遇到了這樣的問題。
默認使用的 markdown 編輯器， 中的 使用的 pattern 已經被拋棄了。而這個 repo 幾乎已經陷入了不維護的狀態，於是我只得引入這個庫到我的項目中，然後自己去修復這些問題。
好在升級起來還是蠻很容易的，後來仔細一讀代碼發現，這個庫只是對 markdown 庫進行了一些封裝。因此，自己動手寫了一個 markdown 的封裝。
7. 清理掉不需要的代碼、文件
早期使用 的時候，留下了不同版本的靜態文件，如早期的 jQuery 1.4.2、jquery-1.7.1.min.js、jquery-1.7.2.min.js 等等。
因此，便直接刪除了舊的靜態文件，這些文件有：
就現在而言，清理這些舊文件，並不會帶來額外的收益。但是，未來就不好說了。
8. 上線前使用線上的環境進行預部署
我在我的伺服器上獲取最新的版本，創建了新的虛擬環境，然後測試：
代碼看來似乎是好的，於是我更新了啟動腳本里的 的路徑，並使用啟動腳本來運行服務。結果，系統並沒有啟動起來——原因是少了 gunicorn。
我忘了在 中加油入 的依賴，
於是，我重新啟動了服務，打開了 phodal.com，發現 500 了又。mdzz，
去看了看日誌，發現線上使用了 memcached 作為數據緩存，這個配置寫在 文件中，但是沒有添加在依賴中。
怪我。
來了，看了，來份關注唄~~
※程序員可以培養的第二技能有哪些？
※前端寫一個月的原生 Android 是怎樣一種體驗？
TAG:phodal |