預釋出環境,Tag釋出機制和可重複的部署過程

這12條測試如下:

1.是否啟用版本控制？

2.是否可以一步建構?

3.是否進行每日建構？

4.是否有bug跟蹤清單？

5.是否在修改bug後，才開始寫新代碼？

6.是否及時更新工作計劃？

7.是否在開發前編寫了大家一緻認可的功能文檔？

8.是否有安靜的工作環境？

9.是否在使用最好的軟體開發工具？

10.是否有專職測試人員？

11.是否在面試時以實際編寫代碼來檢查求職者？

12.是否利用陌生人進行可用性測試？

我的主要工作集中在”Web/Mobile Web”領域，在”Joel Test”寫就的年代，Web技術僅僅是一些用記事本就能寫出的Html頁面。但到了今天，到了經曆過BS浪潮,後端程式設計語言井噴湧現，Ajax和HTML5變得人人皆知的今天。Web技術已經變成了一個由N種後端技術*N種開發語言/架構*N種前端技術交織起來的複雜體系。Web程式員們覺得Joel開出的清單仍然有價值,那是因為我們的大部分工作仍然延續着上一代程式員們開創的軌迹；我們仍然在通過程式代碼釋創造力同時避免BUG的出現;我們仍然得謹慎的在強大,華麗與高效之間做着權衡.相比用戶端,Web技術最大的優勢在于部署成本的節省,我們的程式和Joel年代最大的差別也在于此。這一年來新的工作崗位讓我學到了很多,部署過程正是其中我覺得最值得和大家分享的部分.

1.是否采用了預釋出環境

2.是否以Tag作為釋出機關

3.是否讓部署過程是可重複的

是否采用了預釋出環境

關于測試驅動開發的鼓吹中,”免除對代碼修改的恐懼”十分具有誘惑力.我們都不喜歡功能逐漸豐富過程中冷不防出現的各種BUG,這些BUG打亂我們的計劃,破壞我們的心情,進而讓我們對開發新功能的旅程心存恐懼.TDD的最大魅力也來自于通過測試先行來保證後續的功能擴充相對于預期是可驗證的.不過無論你的WEB開發過程是怎樣的,最終的代碼和内容還是要通過釋出來送達到使用者浏覽器中,你可以對PK需求,修改BUG,延長加班毫無畏懼,但你不能忽略使用者體驗.代碼一旦部署到正式環境上,對你工作的評判不再是項目組中關心你,體諒你的同僚.而是千萬對錯誤零容忍的使用者.在釋出前你已經做過周全的測試?新增的每一項功能已經測試過?很好.不過是在你的開發環境或某處偏僻的”測試環境”中?伺服器OS不一樣,Web Server有差别,緩存服務未啟用,APP容器或解釋器,資料庫版本有差别,沒接通第三方API,這所有的一切都可能會造成釋出後,你自己或使用者重新整理網站後的那聲”What The fuck?”,我想這應該是較之修改BUG,你更不想面對的情景吧.

總的說來,”預釋出環境”就等于沒有真實使用者通路的生産環境,除了讓使用者不能通路到外,盡一切可能讓這個環境和生産環境一緻.每次正式釋出時以這個環境為目标,測試流程完成後.把釋出内容從這個環境”平移”到生産環境.

是否以Tag作為釋出機關

這麼做的好處也是明顯的,雖然我們已經通過預釋出環境規避了大部分釋出環境可能引入的問題.但當那”萬一”發生時.你能夠以最快的速度切換到上一次釋出時的狀态.通常可以通過”$svn switch[上次釋出Tag的SVN路徑]“一行指令搞定.

是否讓部署過程是可重複的

如果你所在的團隊對開發和運維工作進行了嚴格切分,這不會是一個問題.但不是所有項目都會到這個規模,如果你是一個幸福的能變更生産環境的Web程式員,請千萬小心,你對生産環境的每次調整/優化,都可能讓項目部署過程變得不可重複.随着時間的推移,你會忘記當時的配置項.一旦項目需要擴容,恢複,移交.這過程都可能演變成災難.

上面提到那篇文章中,提倡用部署腳本來管理部署過程.這是很好的解決方法,但如果你暫時缺乏系統腳本程式設計能力.分門别類把每次環境配置過程記錄清楚吧,就當這項工作要在你不在場的情況下被别人重複執行.

别人說我們是”碼農”,我們要把自己當工程師.