頻繁釋出可工作的軟體，降低釋出風險－－《持續交付》讀書筆記

最近在看的一本書叫《持續交付－－釋出可靠軟體的系統方法》，在看這本書之前，我曾在持續交付大會上當過志願者，在這個大會上，更多被提及的都是持續整合的一些問題和難點，所以我是帶著持續整合和持續交付有什麼區別這個疑問在讀這本書。

首先先介紹一下概念。

持續交付：頻繁且有規律的釋出可工作的軟體。

持續整合：頻繁的進行程式碼的整合。

雖然這本書叫《持續交付》，事實上，更多的也是在聊持續整合。但是我大概能夠理解二者的區別了。我的理解是，持續整合關注的更多是在實現軟體的層面上，而持續交付關注的是在向客戶交付價值的層面上。對於持續交付來說，持續整合是一個基石，只有做到了持續整合，才能做到持續交付。而只有做到了持續交付，才是真正將持續整合的價值也傳遞出去。

書裡最常提到的一句話：提前並頻繁的做讓你感到痛苦的事。對於開發者來說，很多時候，部署上線是一件很痛苦的事，因為部署上線很多時候是一件風險很高的事，要更新很多的功能。持續交付中提到的頻繁，就是將這件大事，這些很多的功能拆小，每次上線一小點，當出現問題的時候，回滾就是一件容易的事，排查錯誤的範圍也會變小，釋出的風險也就由此降低，痛苦程度也會減弱。

這些都是很籠統的概念，這本書對於我來說就像是一本工具書，介紹了很多的方法如何從無到有的建立一個持續交付的流水線。目前我從這本書中學到的東西就是自動化，向各個環境部署程式碼可以自動化，驗收測試可以自動化，配置各個環境可以自動化，非功能測試可以自動化，什麼都可以自動化。

在讀的時候難免會想到我所在專案組出現過的問題。我們曾出過這樣一個問題，我們引用的第三方軟體的賬號組中某一個賬號出了問題，這個第三方軟體是一個賬號出問題整個組都會被封。當時在生產環境把賬號替換了，但是把其他幾個環境漏掉了，結果在類生產環境跑的時候再次導致問題的發生。加上開發環境，共有四種環境，每次需要新增或者更改第三方軟體配置時，都需要登入各個機子，在不同的模組目錄下進行更改。人手工進行更改這種行為並不是一件可靠且可重複的事情，當出現問題的時候，無法追溯問題的發生。雖然目前這還是一個技術債，現在已經是在還的階段，我們制定的解決方案就是隻在一個地方儲存這些配置，當部署發生的時候，自動將配置根據模組的不同進行分發。

目前還有一個在還的技術債是關於打包的，對於每個環境，都會打一個包，因為每個環境的配置不同。有的時候打包部署上相應的環境這一步會失敗，由於某些檔案或者配置的無端丟失。這個問題是在我看到書裡有一段內容，講的是在通過單元測試後進行打包，打完的這個包會在流水線上傳遞，一直到生產環境上線。之所以要一直傳遞這個包，而不是重新進行打包，是因為兩次的打包的可能會有一定的偏差。而對應環境的配置就存在當前所在的環境上，通過引用即可。這樣當在某一環境部署失敗的時候，也可以很快速的定位到是環境還是程式的問題。這一部分的講解當時啟發了我，當我們幾個開發在討論到相關的技術債的時候，腦中自然想到的便是這個解決方案。

持續交付的內容還有很多，《持續交付》這本書也是我寫讀書筆記以來看的最痛苦的一本書，我看得很慢，雖然作者講得很細，但是很多地方講的很深，很多時候有點兒像工具書，相對來說例子要少一些，我的經驗不多，能夠記住的也不多，當我的經驗再多一些的時候，再回來看看，大概能夠感悟到更多的東西。