
216
| 第廿三章:請釋放我
第 4 步:包裝版本
理想情況下,這是上一個步驟的一部分。
建構一組“版本資訊”說明這個版本與之前的版本有什麼不同:包括新功能與已修復的
bug。(這可以從原始碼控制記錄中自動拉出來。但是 check-in 訊息或許不適合讓客戶看
到 。)
打包程式(建立一個安裝程式映像,CD ISO 映像等)。基於相同的原因,這個步驟也應
該成為自動組建指令碼的一部分。
第 5 步:部署釋出版本
儲存生成的物件,並建立日誌供未來參考。將它們放在共用的檔案伺服器。
測試釋出版!
是的,你已經測試過程式,證明它已經可以釋出了,但是現在你必須測試
這個“釋出”版本,來確保一切都是正確的,而且產品的品質適合發布。
重點
不要在沒有測試最終成品的情況下釋出軟體。
應該要有一個初步的煙霧測試來確保安裝程式是正常的(在所有支援的部署平台上),
以及軟體看起來可以執行並正常動作。
接著執行一些適合這種釋出版本的測試。內部測試的版本可能會由內部測試者來執行測
試腳本。Beta 版本可能會發布給外部測試者。候選版本應該做合適的最終回歸檢查。如
果軟體版本沒有被徹底地檢查,就不應該發布。[Page-208]
最後,部署版本。如果你直接出貨給使用者,可能要將安裝程式放在你的網站,並寄出
email 或電子報。或許這代表軟體被送到工廠,燒錄到實體媒體。
如果你的程式會被即時部署,執行產品伺服器,接著進入
devops
的世界(
development/
operations
,軟體開發與 IT 操作同時進行)。這是部署新程式的遠端伺服器、升級任何 ...