引言
本文摘錄《Continuous Delivery中文版》一書的要點。內文摘錄
第1章 軟體交付的問題
■本書的核心模式是部署流水線(deployment pipeline)。從本質上來說，部署流水線是指「一個應用程式從建置、部署、測試到發佈整個流程的自動化實作。」部署流水線的實作對於每個組織都是不完全相同的，這取於他們對軟體發佈價值流(value stream)的定義，但其背後的原則是相同的。■我們以及與我們一起遵循此方法的實踐者發現，為了達到這些目標(短週期、高品質)，我們需要頻繁且自動化的發佈軟體。
■對於頻繁的自動化發佈而言，「回饋」特別重要。下列是三個關於回饋非常有用的標準：
●無論什麼修改都應該觸發回饋流程；
●回饋應該儘快發送出來；
●交付團隊必須接收回饋，並據此做出相對應的行動。
■追根究柢，軟體部署包括三件事：
●提供並管理你的軟體所需要的執行環境，包括硬體設定、相依性軟體、基礎設施，以及所需的外部服務；
●將應用程式的正確版本安裝於其中；
●設置你的應用程式，包括它所需要的任何資料及狀態。
第2章 設置管理
■為了能夠清晰陳述，此處我們提供設置管理在本書中的定義：●設置管理是指一個流程，透過該流程，所有與專案相關的產出物，以及它們之間的關係都會被唯一定義、修改、儲存和檢索。
■應用程式是由設置資訊、產品程式碼及其資料這三個關鍵部份共同組成。軟體在建置、部署和執行時，我們可以透過設置資訊來改變它的行為。
■管理應用程式設置的問題上，需要回答三個問題：
●如何描述設置資訊？
●部署腳本如何存取這些設置資訊？
●在環境、應用程式，以及應用程式各版本之間，每個設置資訊有何差異？
■需要加以關注的環境設置資訊如下：
●環境中各式各樣的作業系統，包括其版本、修改程式的層次及設置設定；
●應用程式所依存的是需要安裝到每個環境中的套裝軟體，以及這些套裝軟體的具體版本和設置；
●應用程式要正常運作必需的網路拓撲結構；
●應用程式所依存的所有外部服務，以及這些服務的版本和設置資訊；
●既有資料以及其它相關資訊(例如：生產資料庫)。
■虛擬化技術也可以提高環境管理流程的效率。
■應該嚴格控制生產環境，未經組織內部正式的變更管理流程，任何人不得對其進行修改。
第3章 持續整合
■持續整合(continuous integration)最早出現在Kent Beck寫的《Extreme Programming Explained》一書中，該書於1999年首次出版。和其它極限程式設計的實踐相同，持續整合背後的概念是：既然經常整合程式碼庫對我們有好處，為何不隨時整合呢？就整合而言，「隨時」意指每當有人提交程式到版本控制系統時。■「持續整合」是種根本上的觀念顛覆。如果沒有持續整合，你開發的軟體直至(通常是測試或整合階段)有人來驗證它能否運作，將一直處於無法執行狀態。有了持續整合，在每次修改後(假如有足夠全面的自動化測試集合)軟體都會被證明是可執行的。即便它被破壞了，你也能夠很快發現，並立即修復。將持續整合使用得很有效率的團隊會比沒有使用它的團隊更快交付軟體，且缺陷也較少。交付期間，缺陷被發現得越早，修復它的成本就越低，因此也就能大幅度節省成本和時間。因此我們認為，對於專業的軟體交付團隊，持續整合與版本控制同等重要。
■開始做持續整合之前，你需要完成三件事情：
●版本控制；
●自動化建置；
●團隊共識。
■為了使持續整合能夠更效，開始之前，你應該先做好以下這些事情：
●頻繁簽入；
●建立全面的自動化測試套件；
●保持較短的建置和測試流程；
●管理開發工作區。
■必不可少(essential)的實踐：
●建置失敗之後不要簽入新的程式碼；
●提交前先在本地執行全部的提交測試，或是讓持續整合伺服器完成此事；
●等提交測試通過後再繼續工作；
●回家之前，建置必須處於成功狀態；
●隨時準備好恢復到前一個版本；
●在限制時間內修復，否則就還原；
●不要將失敗的測試改為注釋；
●為自己導致的問題負責；
●測試驅動的開發。
■推薦(suggested)的實踐
●極限程式設計開發實踐；
●若違背架構原則，就讓建置失敗；
●若測試運行變慢，就讓建置失敗；
●若有編譯警告或程式碼風格的問題，就讓建置失敗。
■持續整合的實施還會迫使你遵循另外兩個重要的實踐：良好的設置管理，以及建立並維護一個自動化建置和測試流程。
第4章 測試策略的實作
■一個理想的專案裡，專案一開始，測試人員就會與開發人員及客戶一起編寫自動化測試。這些測試應該在開發人員要開始開發需要測試的特性之前就寫好。如此一來，這些測試就成為一個可執行而且是從系統行為角度來描述的需求規格說明書。當這些測試全部通過後，也就表示客戶所需功能已經被完全且正確的實作了。每次對應用程式進行修改時，持續整合系統都會執行這些自動化測試套件，因此這些測試套件也是個迴歸測試集合。第5章 部署流水線解析
■從某種抽象層次上來說，「部署流水線」是指軟體從版本控制到使用者手中期間的自動化表現形式。對軟體每次變更都會經歷一個複雜流程才能發佈。此流程包括建置軟體，以及後續一系列不同階段的測試與部署，而這些活動通常都需要許多人或是許多個團隊之間的共同合作。部署流水線是對此流程的建模，在持續整合和發佈管理工具上，它能具體呈現出查看與控制每個變更的整個歷程，包括每次變更被提交到版本控制開始，直到通過各種測試和部署，最後發佈給使用者。■基本的部署流水線。
●對價值流建模，並建立一個可以使用的簡單架構；
●將建置和部署流程自動化；
●將單元測試和程式碼分析自動化；
●將驗收測試自動化；
●將發佈自動化。
第6章 建置與部署的腳本化
■對於非常簡單的專案，我們使用IDE (Integrated Development Environment，整合式開發環境)就可以進行軟體的建置和測試。然而，這卻只適合最簡單的任務。只要專案所需人力超過兩個人，或是需要好幾個月的開發時間，或是輸出了一個以上的可執行檔，若不想讓它變得太過複雜又難以處理，就需要施加更多控制了。大型或分散式團隊(包括開放程式碼專案)中，使用腳本執行應用程式的建置、測試和package是必須的，否則團隊的新成員就要花上好幾天才能熟悉專案。■建置與部署腳本化的原則與實踐：
●為部署流水線的每個階段建立腳本；
●使用合適的技術部署應用程式；
●使用相同的腳本部署所有環境；
●使用作業系統附帶的套件管理工具；
●確保部署流程是冪等(idempotent)的；
●令部署系統以增量的形式來演進。
第7章 提交階段
■提交階段的原則和實踐：●提供快速且有用的回饋；
●決定何時應該讓提交階段失敗，以及維持提交失敗時即刻修復的紀律；
●精心對待提交階段；
●讓開發人員也擁有所有權；
●為超大型的專案團隊指定建置負責人。
第8章 自動化驗收測試
■整體而言，本書一直試圖避免限制你所使用的開發流程。我們相信，我們所描述的這些模式對所有交付團隊都有好處，無論這些團隊使用何種形式的開發流程。然而，我們仍舊認為，對於建立高品質的軟體，iterative的開發流程是至關重要的。因此，若在此談到iterative的開發流程較多，請你諒解，因為它有助於勾勒出分析人員、測試人員和開發人員的角色。■對於使用iterative流程的專案而言，由於自動化測試變得更重要，因此，許多實踐者都意識到，自動化不僅是測試而已。相反的，驗收測試就是開發中軟體行為的可執行需求規格說明書。此為自動化測試的新方法之一，其被稱為行為驅動開發(behavior-driven development)。行為驅動開發的核心理念之一就是：驗收測試應該以客戶期望的應用程式行為來書寫。如此一來，即可拿這些已寫好的驗收標準直接在應用程式上執行，即可驗證它是否滿足需求規格。
■此種建立可執行需求規格的方法是行為驅動的設計本質。讓我們再複習一下此流程：
●和客戶一起討論使用者故事的驗收標準；
●以可執行的格式將得到的驗收標準寫下來；
●為這些使用領域專屬語言(domain-specific language)所描述的測試寫出它的程式碼實作，為應用程式驅動層進行互動。
●建立應用程式驅動層，使測試透過它來與系統互動。
第9章 非功能性需求的測試
■性能(performance)是指處理單一事務所費時間的指標之一，既可用於單獨衡量，也可以在一定的負載下衡量。輸送量(throughput)是系統在一定時間內能處理的事務數量，通常它受限於系統中的某個瓶頸。一定的工作負載下，當每個單獨請求的回應時間維持在可接受的範圍內，該系統所能承擔的最大輸送量被稱為它的容量(capacity)。客戶一般都對輸送量和容量較有興趣。現實生活中，「性能」常被用來表示這些用語的合集(catch-all term)，本章會小心的使用它們。■如何設計出滿足非功能性需求的系統是個很複雜的問題。許多非功能性需求的橫切本質(crosscutting nature)意味著，它們為專案中帶來的風險是難以管理的。結果，這也經常導致兩種不適當的作法：從專案一開始就未能足夠的注意它們，或是另一個極端，如：預防性的架構及過度的設計。
第10章 應用程式的部署與發佈
■提示與技巧：●真正執行部署操作的人應該參與部署流程的建立；
●記錄部署活動；
●不要刪除舊檔，而是移動到別的位置；
●部署是整個團隊的責任；
●伺服器應用程式不應該有GUI；
●為新部署留預熱期；
●快速失敗；
●不要直接對生產環境進行修改。
第11章 管理基礎設施與環境
■準備部署環境的流程，以及部署後對環境的管理是本章的主要內容。然而為了能夠做到這點，就得根據下列這些原則，使用全面性的方法來管理所有基礎設施：●使用保存於版本控制中的設置資訊來指定基礎設施所處的狀態；
●基礎設施應該具有自主的特性，意即它應該自動將其設定到所需的狀態；
●透過測試設備和監控手段，應該時時刻刻都能掌握基礎設施的即時狀況。
■為了減少類生產環境(production-like environment)中的部署風險，需要精心管理以下內容：
●作業系統及其設置資訊，包括測試環境和生產環境；
●中間件軟體堆疊及其設置資訊，包括應用程式伺服器、訊息系統和資料庫；
●基礎設施軟體，例如：版本控制儲存庫、目錄服務，以及監控系統；
●外部整合點，例如：外部系統和服務；
●網路基礎設施，包括路由器、防火牆、交換器、DNS和DHCP等；
●應用程式開發團隊與基礎設施管理團隊之間的關係。
■就像開發人員透過寫自動化測試做行為驅動開發來驗證應用程式的行為，業務人員也能寫自動化測試來驗證基礎設施的行為。可以先編寫一個測試，驗證它是失敗的，接著定義Puppet manifest(或是任何正在使用的設置管理工具)讓基礎設施達到所期望的狀態。接下來執行此測試來驗證此種設置可以正確工作，且基礎設定的行為與期望的行為一致。
■如果你正在對企業系統中的合作廠商產品進行可用性評估，請確保「是否已滿足自動化設置的管理策略」位於評估標準清單中佔有較高的優先順序。哦！請幫幫忙，如果供應商的產品在這方面的表現較差，給他們一個硬性時間來回應。對於嚴格的設置管理支援方面，許多供應商都是十分草率且敷衍了事的。
第12章 資料管理
■持續整合要求每次修改應用程式後，它都能夠正常的執行。這也包括修改資料結構與內容。持續交付要求我們必須能夠將應用程式中任何已通過驗證的版本(包括對資料庫變更的版本)部署到生產環境(對於使用者自行安裝與包含資料庫的軟體也是相同的)。除了那些最簡單的系統，對資料庫進行更新的同時，還要保留它們的資料。最後，由於在部署時需要保留資料庫中的既有資料，所以需要有還原策略，以便在部署失敗時能使用。■即使有了自動化的資料庫遷移流程，細心管理測試資料仍舊是非常必要的。儘管直接使用生產資料庫的副本是個充滿誘惑力的選擇，但通常會因為資料過於龐大反而不容易使用。相反的，應該讓測試自行建立它們所需的狀態，並確保每個測試都能獨立於其它測試。甚至做手動測試時，也得儘量不要使用到生產環境中的資料庫副本，它不是最佳的起始點。測試人員應該根據測試目的來建立並管理自己的最小資料集合。
第13章 元件和相依性管理
■元件(component)是什麼？軟體領域中，此用語的使用已呈現氾濫的情形，因此使用此用語前，我們試著給予它一個明確的定義。我們提到元件時，是指應用程式中一個規模相當大的程式碼結構，它具有一套定義良好的API，而且可以被另一種實作方式所取代。通常一個以元件為基礎的軟體系統之程式碼庫被分成多個相互分離的部分，透過個數有限且定義良好的介面來提供一些服務行為，每個部分即可與其它元件進行有限的互動。■為了在變更的同時還能保持應用程式的可發佈，有下最四種策略：
●將新功能隱蔽起來，直到它完成為止。
●將全部的變更都變成一系列的小型增量式修改，並讓每個小型修改都是可發佈的。
●使用透過抽象來虛擬出分支(branch by abstraction)的方式對程式碼庫進行大範圍變更。
●使用元件，根據不同部分的修改頻率對應用程式進行解耦合。
第14章 版本控制進階
■分支的理由有三種。第一，為了發佈應用程式的新版本要建立分支。讓開發人員能夠不斷開發新特性，卻不會影響對外發佈版本的穩定性。若發現bug，可先在對外發佈相對應的分支上修復，接著再把修補程式合併到主線上。該發佈分支從不合併回主線。第二，需要調查與研究新特性或進行重構時–研究調查用的分支最終會被丟棄且從不被合併到主線。第三，若需要對應用程式做較大幅度的修改，又無法使用上一章所描述的方法來避免分支時，也可以使用生命週期較短的分支(其實，如果程式碼庫結構良好，此種情況也很少見)。分支的唯一目的就是為了對程式碼進行增量式或「透過抽象來虛擬分支」方式的修改。第15章
■設置與發佈管理成熟度模型。| 實踐 | 建置管理和持續整合 | 環境與部署 | 發佈管理和符合性(compliance) | 測試 | 資料管理 | 設置 |
| 3級(最佳化)： 聚焦於流程的持續改進 | 團隊定期碰面，討論整合問題，並已利用自動化、回饋較快和良好的可視化來解決這些問題。 | 較有效的管理所有環境。準備工作全部自動化。若合適就會使用虛擬化技術。 | 業務和交付團隊定期溝通來管理風險，以縮短迴圈週期。 | 生產環境的還原已很少見。缺陷可以立即被發現並修復。 | 在兩次發佈之間建立了資料庫性能和部署流程的回饋迴路。 | 定期驗證設置管理是否支援有效率的合作，快速開發和可審核的變更管理流程。 |
| 2級(量化管理)： 流程計量與控制 | 建置計量蒐集、可視化並採取行動。建置不能長時間處於失敗的狀態。 | 有精心計畫的部署管理，對發佈和還原流程進行測試。 | 環境與應用程式的健康性受到監控，並有前瞻性管理；週期時間(cycle time)得到關注與監控。 | 品質計量和趨勢追蹤。對於非功能性需求進行了定義與計量。 | 每次部署都進行資料庫升級和還原測試。對資料庫進行監控和最佳化。 | 開發人員每天至少簽入主線一次。只在需要發佈時才會產生分支。 |
| 1級(一致性)： 在整個應用程式生命週期中使用自動化流程 | 每次程式碼提交都進行自動化建置和測試。相依關係被妥善管理。腳本與工具的妥善使用。 | 軟體部署使用全自動自主服務的一鍵式流程。使用相同的流程部署各種環境。 | 定義並執行變更管理和審核流程。監管及符合規定的標準獲得滿足。 | 自動化的單元測試和驗收測試。後者是測試人員所編寫。測試已是開發期間的一部分。 | 資料庫變更成為部署流程的一部分自動執行。 | 函式庫和相依性已被妥善管理。變更管理流程會決定版本控制的使用規則。 |
| 0級(可重複性)： 流程皆被文件記錄下來了，且已有部分已自動化 | 定期的自動化建置與測試。任何建置都可以使用自動化處理由原始程式碼控制重新建立。 | 自動化部署到幾種環境中。新環境的建立成本非常低。所有設置都被放在外部，且有版本控制。 | 痛苦且不頻繁，但能可靠發佈。從需求到發佈可以做到部分可追蹤。 | 自動化測試是使用者故事開發的一部分。 | 使用自動化腳本完成資料庫的變更，而這些腳本會與應用程式的版本相對應。 | 重建軟體所需的內容都有版本控制，包括：原始程式、設置、建置與部署腳本、資料移轉。 |
| -1級(阻礙的)： 流程不可重複，受控性差，具有反作用的 | 軟體建置是手動流程。沒有管理產出物和報告。 | 軟體部署是手動流程。具體環境限定的binary套件。環境準備是手動的。 | 不頻繁且不可靠的發佈。 | 開發完之後才做手動測試。 | 資料庫遷移沒有版本化，且手動進行。 | 沒有使用版本控制，或是簽入不頻繁。 |
沒有留言:
張貼留言