持續傳遞之一——軟體交付的問題

標籤：

其他持續傳遞相關文章：《持續傳遞》系列文章目錄

第一章 軟體交付的問題1. 引言

本書的核心模式是部署流水線，以持續整合理論作為其理論基石

部署流水線有三個目標

• 讓軟體構建，部署，測試和發布過程對所有人可見，促進合作
• 改善反饋，能在整個過程中更早的發現和解決問題（做一件事，有問題發生是一定的，重要的是快速的定位和解決問題）
• 使在任何環境下部署和發布任意版本的應用成為自動化的過程，提高效率

一個簡單的簡單的部署流水線

提交階段 ==> 自動化驗收測試 ==> 自動化容量測試 ==> 手工測試 ==> 發布

2. 一些常見的反模式2.1. 反模式：手工部署軟體

這個反模式一般具有如下特徵

• 有一份詳盡的操作文檔，其中描述了多出需要注意的地反
• 手工測試程式是否運行正確
• 總有客戶來問，部署怎麼又出問題了
• 如果是叢集環境，個環境配置經常有出入
• 發布過程時間較長
• 發布結果無法預測（憑運氣）
• 經常加班，還搞不定問題

理想的部署流程應該是

1. 挑選要部署的版本和環境
2. 按一下“部署”按鈕

為什麼需要部署自動化

• 使部署過程可重複
• 免去部署文檔的維護，一個部署指令碼即是所有文檔
• 部署過程可審計追蹤
• 擺脫對人的過分依賴

2.2. 反模式：開發完成之後才向生產環境部署

經常出現的情況

• 營運人員之前一直沒有接觸過應用程式
• 程式相關的配置，資料庫指令碼，部署文檔等都沒有在正式環境下測試過
• Team Dev和營運團隊協作太少

導致的各種問題

• 第一次部署成了噩夢
• 開發環境和部署環境差距越大，問題越多
• 各團隊之間協作焦頭爛額

解決方案

將測試，部署和發行活動都納入到開發過程中，讓他們成為正常開發流程的一部分，對部署過程也進行測試

2.3. 反模式：生產環境的手工配置

這種反模式經常有如下特徵

• 誒，我本地好使啊
• 叢集中各節點表現不同
• 每次準備環境事件長
• 無法復原
• 不知不覺，叢集中的伺服器，作業系統配置變得都不一樣了

怎樣解決這些問題？

採用組態管理，可以重複的建立開發應用程式所需要的每個基礎設施

對於各個環境中的資訊，都應該完全掌控，而且，所有環境的產生，配置的修改都應該由自動化程式實現，禁止手動修改

2.4. 如何改變這種情況

採用部署流水線，將軟體的發布變成一種低風險、頻繁、廉價、迅速且可預見的過程

最後的目標是實現將自動化的測試和部署，以及全面的組態管理結合在一起，實現一鍵式軟體發布

3. 如何?目標

為保證能持續的以高品質交付我們的軟體，需要頻繁的自動化發布軟體

對於頻繁的自動化發布軟體，反饋是至關重要的，對於反饋，應該達到三個標準

• 無論什麼樣的修改都應該觸發反饋流程
• 反饋應該儘快發出
• 交付團隊必須接收反饋，並依據它做出行動響應

下面詳細介紹一下這三個標準

3.1. 無論什麼樣的修改都應該觸發反饋流程

這些修改包括對以下項的修改

1. 原始碼（持續整合)
2. 配置資訊(組態管理)
3. 運行環境(基礎設施和環境管理)
4. 資料(資料管理)

反饋流程

完全自動化的方式儘可能的測試每一次變更

測試內容包括但不限於

• 建立可執行代碼的流程必須是能奏效的。這用於驗證原始碼是否符合文法
• 軟體的單元測試必須是成功的。這可以檢查應用程式的行為是否與期望相同
• 軟體應該滿足一定的品質標準，比如測試覆蓋率以及其他與技術相關的度量項
• 軟體的功能驗收測試必須是成功的。這可以檢查應用是否滿足業務驗收準則，交付了所期望的業務價值
• 軟體的非功能測試必須是成功的。這可以檢查應用程式是否滿足使用者對效能、有效性、安全性等方面的要求
• 軟體必須通過了探索性測試，並給客戶以及部分使用者做過示範。這些通常在一個手工測試環境上完成。此時，產品負責人可能認為軟體功能還有缺失，我們自己也可能發現需要修複的缺陷，還要為其寫自動化測試來避免迴歸測試

3.2. 反饋應該儘快發出

關鍵是自動化，主要通過部署流水線來實現，後面各章會詳細介紹

3.3. 交付團隊必須接收反饋，並依據它做出行動響應

沒有響應，反饋何用？

3.4. 這個流程可以推廣嗎

很多思想來源於精益製造，目標是快速交付高品質的產品，聚焦於消除浪費，減少成本

這個思想已經被多個行業所證明，而且作者也經曆過很多採用更持續傳遞的項目

4. 收效4.1. 授權團隊

讓整個團隊合作在一起

4.2. 較少錯誤

通過減少手工的重複任務，避免大部分錯誤

4.3. 緩解壓力

讓發布任務變得簡單可控，免得每次發布都如臨大敵

4.4. 部署的靈活性

隨時找到以往的部署版本，意見部署任意版本

4.5. 多加練習，使其完美

目標是不管部署到什麼環境，都使用相同的部署方法

5. 候選版版本

每次提交代碼都產生一個可發布版本

但是實際開發中，要想驗證一個可發布版本，就要進行一次整合，通常這個過程難以控制，所以就會延遲，整合頻率越低，越痛苦，但是越痛苦的事，越要頻繁去做，要麼會更痛苦

本書會通過持續整合這一實踐來讓整合變得無痛

6. 軟體交付的原則

為了保證高品質的持續傳遞，下面的可以當做管理辦法了

6.1. 為軟體的發布建立一個可重複且可靠的過程

歸根結底，軟體的部署套件括三件事

• 提供並管理軟體所需要的運行環境，包括硬體設定，所依賴的軟體，基礎設施以及所需的外部服務
• 將應用程式的正確版本安裝其上
• 配置應用程式，包括所需的任何資料和狀態

6.2. 將幾乎所有的事情自動化

能讓機器去做的就別自己做了

6.3. 把所有的東西都納入版本控制

使每個版本相關的資訊都能很快找到

6.4. 提前並頻繁的做讓你感到痛苦的事

這是一條很有用的啟發學習法原則

6.5. 內建品質

每個人都對品質負責，有問題立馬解決

6.6. “DONE”意味著“發行”

我們認為一個特性只有交到使用者手中才算DONE，而不是開發完了就OK了

6.7. 交付過程是每個成員的責任

從相互指責扯皮到共同協作

6.8. 持續改進

戴明環（plan->do->check->act）

7. 小結

本書的目標是讓發布過程變得無痛

持續傳遞之一——軟體交付的問題