☆☆☆☆☆




點擊這裡下載

類似圖書 點擊查看全場最低價

---

産品特色

編輯推薦

　　

　 第21屆Jolt大奬獲奬作品
　　　 馬丁·福勒作序推薦
　　　 原著被譽為2010年重要的技術書
　　　 軟件開發的新經典
　　
　　　 《持續交付：發布可靠軟件的係統方法》是一本軟件工程師的職場指南，以大量虛構的名字和情景描述瞭極客的日常工作，對他們常遇到的各類棘手問題給予瞭巧妙迴答。作者以自己在蘋果、網景等公司中麵臨的生死攸關的時刻所做的抉擇為例，總結瞭在矽榖摸爬滾打的經驗，旨在為軟件工程師更好地規劃自己的職業生涯提供幫助。

內容簡介

　　《持續交付：發布可靠軟件的係統方法》講述如何實現更快、更可靠、低成本的自動化軟件交付，描述瞭如何通過增加反饋，並改進開發人員、測試人員、運維人員和項目經理之間的協作來達到這個目標。本書由三部分組成。第一部分闡述瞭持續交付背後的一些原則，以及支持這些原則的實踐。第二部分是本書的核心，全麵講述瞭部署流水綫。第三部分圍繞部署流水綫的投入産齣討論瞭更多細節，包括增量開發技術、高級版本控製模式，以及基礎設施、環境和數據的管理和組織治理。
　　
　　《持續交付：發布可靠軟件的係統方法》適閤所有開發人員、測試人員、運維人員和項目經理學習參考。

作者簡介

　　Jez Humble，ToughtWorks公司首席谘詢顧問，緻力於幫助企業快速、可靠地交付高質量軟件，經常在各種敏捷技術大會上發錶演講，擁有牛津大學物理學學士學位和 倫敦大學民族音樂學的碩士學位。2000年至今，他曾在各行業和不同技術領域擔任係統管理員、開發人員、培訓人員、谘詢師和經理人員。

目錄

第一部分 基礎篇
第1 章 軟件交付的問題
1.1 引言
1.2 一些常見的發布反模式
1.2.1 反模式：手工部署軟件
1.2.2 反模式：開發完成之後纔嚮類生産環境部署
1.2.3 反模式：生産環境的手工配置管理
1.2.4 我們能做得更好嗎
1.3 如何實現目標
1.3.1 每次修改都應該觸發反饋流程
1.3.2 必須盡快接收反饋
1.3.3 交付團隊必須接收反饋並作齣反應
1.3.4 這個流程可以推廣嗎
1.4 收效
1.4.1 授權團隊
1.4.2 減少錯誤
1.4.3 緩解壓力
1.4.4 部署的靈活性
1.4.5 多加練習，使其完美
1.5 候選發布版本
1.6 軟件交付的原則
1.6.1 為軟件的發布創建一個可重復且可靠的過程
1.6.2 將幾乎所有事情自動化
1.6.3 把所有的東西都納入版本控製
1.6.4 提前並頻繁地做讓你感到痛苦的事
1.6.5 內建質量
1.6.6 “DONE”意味著“已發布”
1.6.7 交付過程是每個成員的責任
1.6.8 持續改進
1.7 小結
第2 章 配置管理
2.1 引言
2.2 使用版本控製
2.2.1 對所有內容進行版本控製
2.2.2 頻繁提交代碼到主乾
2.2.3 使用意義明顯的提交注釋
2.3 依賴管理
2.3.1 外部庫文件管理
2.3.2 組件管理
2.4 軟件配置管理
2.4.1 配置與靈活性
2.4.2 配置的分類
2.4.3 應用程序的配置管理
2.4.4 跨應用的配置管理
2.4.5 管理配置信息的原則
2.5 環境管理
2.5.1 環境管理的工具
2.5.2 變更過程管理
2.6 小結
第3 章 持續集成
3.1 引言
3.2 實現持續集成
3.2.1 準備工作
3.2.2 一個基本的持續集成係統
3.3 持續集成的前提條件
3.3.1 頻繁提交
3.3.2 創建全麵的自動化測試套件
3.3.3 保持較短的構建和測試過程
3.3.4 管理開發工作區
3.4 使用持續集成軟件
3.4.1 基本操作
3.4.2 鈴聲和口哨
3.5 必不可少的實踐
3.5.1 構建失敗之後不要提交新代碼
3.5.2 提交前在本地運行所有的提交測試，或者讓持續集成服務器完成此事
3.5.3 等提交測試通過後再繼續工作
3.5.4 迴傢之前，構建必須處於成功狀態
3.5.5 時刻準備著迴滾到前一個版本
3.5.6 在迴滾之前要規定一個修復時間
3.5.7 不要將失敗的測試注釋掉
3.5.8 為自己導緻的問題負責
3.5.9 測試驅動的開發
3.6 推薦的實踐
3.6.1 極限編程開發實踐
3.6.2 若違背架構原則，就讓構建失敗
3.6.3 若測試運行變慢，就讓構建失敗
3.6.4 若有編譯警告或代碼風格問題，就讓測試失敗
3.7 分布式團隊
3.7.1 對流程的影響
3.7.2 集中式持續集成
3.7.3 技術問題
3.7.4 替代方法
3.8 分布式版本控製係統
3.9 小結
第4 章 測試策略的實現
4.1 引言
4.2 測試的分類
4.2.1 業務導嚮且支持開發過程的測試
4.2.2 技術導嚮且支持開發過程的測試
4.2.3 業務導嚮且評價項目的測試
4.2.4 技術導嚮且評價項目的測試
4.2.5 測試替身
4.3 現實中的情況與應對策略
4.3.1 新項目
4.3.2 項目進行中
4.3.3 遺留係統
4.3.4 集成測試
4.4 流程
4.5 小結

第二部分 部署流水綫
第5 章 部署流水綫解析
5.1 引言
5.2 什麼是部署流水綫
5.3 部署流水綫的相關實踐
5.3.1 隻生成一次二進製包
5.3.2 對不同環境采用同一部署方式
5.3.3 對部署進行冒煙測試
5.3.4 嚮生産環境的副本中部署
5.3.5 每次變更都要立即在流水綫中傳遞
5.3.6 隻要有環節失敗，就停止整個流水綫
5.4 提交階段
5.5 自動化驗收測試之門
5.6 後續的測試階段
5.6.1 手工測試
5.6.2 非功能測試
5.7 發布準備
5.7.1 自動部署與發布
5.7.2 變更的撤銷
5.7.3 在成功的基礎上構建
5.8 實現一個部署流水綫
5.8.1 對價值流進行建模並創建簡單的可工作框架
5.8.2 構建和部署過程的自動化
5.8.3 自動化單元測試和代碼分析
5.8.4 自動化驗收測試
5.8.5 部署流水綫的演進
5.9 度量
5.10 小結
第6 章 構建與部署的腳本化
6.1 引言
6.2 構建工具概覽
6.2.1 Make
6.2.2 Ant
6.2.3 NAnt 與 MSBuild
6.2.4 Maven
6.2.5 Rake
6.2.6 Buildr
6.2.7 Psake
6.3 構建部署腳本化的原則與實踐
6.3.1 為部署流水綫的每個階段創建腳本
6.3.2 使用恰當的技術部署應用程序
6.3.3 使用同樣的腳本嚮所有環境部署
6.3.4 使用操作係統自帶的包管理工具
6.3.5 確保部署流程是冪等的（Idempotent）
6.3.6 部署係統的增量式演進
6.4 麵嚮JVM 的應用程序的項目結構
6.5 部署腳本化
6.5.1 多層的部署和測試
6.5.2 測試環境配置
6.6 小貼士
6.6.1 總是使用相對路徑
6.6.2 消除手工步驟
6.6.3 從二進製包到版本控製庫的內建可追溯性
6.6.4 不要把二進製包作為構建的一部分放到版本控製庫中
6.6.5 “test”不應該讓構建失敗
6.6.6 用集成冒煙測試來限製應用程序
6.6.7 .NET 小貼士
6.7 小結
第7 章 提交階段
7.1 引言
7.2 提交階段的原則和實踐
7.2.1 提供快速有用的反饋
7.2.2 何時令提交階段失敗
7.2.3 精心對待提交階段
7.2.4 讓開發人員也擁有所有權
7.2.5 在超大項目團隊中指定一個構建負責人
7.3 提交階段的結果
7.4 提交測試套件的原則與實踐
7.4.1 避免用戶界麵
7.4.2 使用依賴注入
7.4.3 避免使用數據庫
7.4.4 在單元測試中避免異步
7.4.5 使用測試替身
7.4.6 最少化測試中的狀態
7.4.7 時間的僞裝
7.4.8 蠻力
7.5 小結
第8 章 自動化驗收測試
8.1 引言
8.2 為什麼驗收測試是至關重要的
8.2.1 如何創建可維護的驗收測試套件
8.2.2 GUI 上的測試
8.3 創建驗收測試
8.3.1 分析人員和測試人員的角色
8.3.2 迭代開發項目中的分析工作
8.3.3 將驗收條件變成可執行的規格說明書
8.4 應用程序驅動層
8.4.1 如何錶述驗收條件
8.4.2 窗口驅動器模式：讓測試與GUI 解耦
8.5 實現驗收測試
8.5.1 驗收測試中的狀態
8.5.2 過程邊界、封裝和測試
8.5.3 管理異步與超時問題
8.5.4 使用測試替身對象
8.6 驗收測試階段
8.6.1 確保驗收測試一直處於通過狀態
8.6.2 部署測試
8.7 驗收測試的性能
8.7.1 重構通用任務
8.7.2 共享昂貴資源
8.7.3 並行測試
8.7.4 使用計算網格
8.8 小結
第9 章 非功能需求的測試
9.1 引言
9.2 非功能需求的管理
9.3 如何為容量編程
9.4 容量度量
9.5 容量測試環境
9.6 自動化容量測試
9.6.1 通過UI 的容量測試
9.6.2 基於服務或公共API 來錄製交互操作
9.6.3 使用錄製的交互模闆
9.6.4 使用容量測試樁開發測試
9.7 將容量測試加入到部署流水綫中
9.8 容量測試係統的附加價值
9.9 小結
第10 章 應用程序的部署與發布
10.1 引言
10.2 創建發布策略
10.2.1 發布計劃
10.2.2 發布産品
10.3 應用程序的部署和晉級
10.3.1 首次部署
10.3.2 對發布過程進行建模並讓構建晉級
10.3.3 配置的晉級
10.3.4 聯閤環境
10.3.5 部署到試運行環境
10.4 部署迴滾和零停機發布
10.4.1 通過重新部署原有的正常版本來進行迴滾
10.4.2 零停機發布
10.4.3 藍綠部署
10.4.4 金絲雀發布
10.5 緊急修復
10.6 持續部署
10.7 小貼士和竅門
10.7.1 真正執行部署操作的人應該參與部署過程的創建
10.7.2 記錄部署活動
10.7.3 不要刪除舊文件，而是移動到彆的位置
10.7.4 部署是整個團隊的責任
10.7.5 服務器應用程序不應該有GUI
10.7.6 為新部署留預熱期
10.7.7 快速失敗
10.7.8 不要直接對生産環境進行修改
10.8 小結

第三部分 交付生態圈
……

精彩書摘

　　軟件交付的問題
　　1.1　引言
　　作為軟件從業人員，我們麵臨的最重要問題就是，如果有人想到瞭一個好點子，我們如何以最快的速度將它交付給用戶？本書將給齣這個問題的答案。
　　我們將專注於構建、部署、測試和發布過程，因為相對於軟件生産全過程的其他環節來說，這部分內容的論著較為稀少。確切地說，我們並不認為軟件開發方法不重要，如果沒有對軟件生命周期中其他方麵的關注，隻把它們作為全部問題的次要因素草率對待的話，就不可能實現可靠、迅速且低風險的軟件發布，無法以高效的方式將我們的勞動成果交到用戶手中。
　　現在有很多種軟件開發方法，但它們主要關注於需求管理及其對開發工作的影響。市麵上也有很多優秀的書，它們詳細討論瞭在軟件設計、開發和測試方麵各種各樣的方法，但它們都僅僅講述瞭將軟件交付給作為客戶的人或組織這一完整價值流的一部分。
　　一旦完成瞭需求定義以及方案的設計、開發和測試，我們接下來做什麼？我們如何協調這些活動，盡可能地使交付過程更加可靠有效呢？我們如何讓開發人員、測試人員，以及構建和運維人員在一起高效地工作呢？
　　本書描述瞭軟件從開發到發布這一過程的有效模式。書中講述瞭幫助大傢實現這種模式的技術和最佳實踐，展示瞭它與軟件交付中其他活動是如何聯係的。
　　本書的中心模式是部署流水綫。從本質上講，部署流水綫就是指一個應用程序從構建、部署、測試到發布這整個過程的自動化實現。部署流水綫的實現對於每個組織都將是不同的，這取決於他們對軟件發布的價值流的定義，但其背後的原則是相同的。
　　部署流水綫的示例如圖1-1所示。
　　部署流水綫大緻的工作方式如下。對於應用程序的配置、源代碼、環境或數據的每個變更都會觸發創建一個新流水綫實例的過程。流水綫的首要步驟之一就是創建二進製文件和安裝包，而其餘部分都是基於第一步的産物所做的一係列測試，用於證明其達到瞭發布質量。每通過一步測試，我都會更加相信這些二進製文件、配置信息、環境和數據所構成的特殊組閤可以正常工作。如果這個産品通過瞭所有的測試環節，那麼它就可以發布瞭。
　　圖1-1　一個簡單的部署流水綫
　　部署流水綫以持續集成過程為其理論基石，從本質上講，它是采納持續集成原理後的自然結果。
　　部署流水綫的目標有三個。首先，它讓軟件構建、部署、測試和發布過程對所有人可見，促進瞭閤作。其次，它改善瞭反饋，以便在整個過程中，我們能夠更早地發現並解決問題。最後，它使團隊能夠通過一個完全自動化的過程在任意環境上部署和發布軟件的任意版本。
　　1.2　一些常見的發布反模式
　　軟件發布的當天往往是緊張的一天。為什麼會這樣呢？對於大多數項目來說，在整個過程中，發布時的風險是比較大的。
　　在許多軟件項目中，軟件發布是一個需要很多手工操作的過程。首先，由運維團隊獨自負責安裝好該應用程序所需的操作係統環境，再把應用程序所依賴的第三方軟件安裝好。其次，要手工將應用程序的軟件産物復製到生産主機環境，然後通過Web服務器、應用服務器或其他第三方係統的管理控製颱復製或創建配置信息，再把相關的數據復製一份到環境中，最後啓動應用程序。假如這是個分布式的或麵嚮服務的應用程序，可能就需要一部分一部分地完成。
　　如上所述，發布當天緊張的原因應該比較清楚瞭：在這個過程中有太多步驟可能齣錯。假如其中有一步沒有完美地執行，應用程序就無法正確地運行。一旦發生這種情況，我們很難一下子說清楚哪裏齣瞭錯，或到底是哪一步齣瞭錯。
　　本書其他部分將討論如何避免這些風險，如何減少發布當天的壓力，以及如何確保每次發布的可靠性都是可預見的。
　　在此之前，讓我們先明確到底要避免哪類失敗。下麵列齣瞭與可靠的發布過程相對應的幾種常見的反模式，它們在我們這個行業中屢見不鮮。
　　1.2.1　反模式：手工部署軟件
　　對於現在的大多數應用程序來說，無論規模大小，其部署過程都比較復雜，而且包含很多非常靈活的部分。許多組織都使用手工方式發布軟件，也就是說部署應用程序所需的步驟是獨立的原子性操作，由某個人或某個小組來分彆執行。每個步驟裏都有一些需要人為判斷的事情，因此很容易發生人為錯誤。即便不是這樣，這些步驟的執行順序和時機的不同也會導緻結果的差異性，而這種差異性很可能給我們帶來不良後果。
　　這種反模式的特徵如下。
　　· 有一份非常詳盡的文檔，該文檔描述瞭執行步驟及每個步驟中易齣錯的地方。
　　· 以手工測試來確認該應用程序是否運行正確。
　　· 在發布當天開發團隊頻繁地接到電話，客戶要求解釋部署為何會齣錯。
　　· 在發布時，常常會修正一些在發布過程中發現的問題。
　　· 如果是集群環境部署，常常發現在集群中各環境的配置都不相同，比如應用服務器的連接池設置不同或文件係統有不同的目錄結構等。
　　· 發布過程需要較長的時間（超過幾分鍾）。
　　· 發布結果不可預測，常常不得不迴滾或遇到不可預見的問題。
　　· 發布之後淩晨兩點還睡眼惺忪地坐在顯示器前，絞盡腦汁想著怎麼讓剛剛部署的應用程序能夠正常工作。
　　相反，隨著時間的推移，部署應該走嚮完全自動化，即對於那些負責將應用程序部署到開發環境、測試環境或生産環境的人來說，應該隻需要做兩件事：（1）挑選版本及需要部署的環境，（2）按一下“部署”按鈕。對於套裝軟件的發布來說，還應該有一個創建安裝程序的自動化過程。
　　我們將在本書中討論很多自動化問題。當然，並不是所有的人都熱衷於這個想法。那麼，我們先來解釋一下為什麼把自動化部署看做是一個必不可少的目標。
　　· 如果部署過程沒有完全自動化，每次部署時都會發生錯誤。唯一的問題就是“該問題嚴重與否”而已。即便使用良好的部署測試，有些錯誤也很難追查。
　　· 如果部署過程不是自動化的，那麼它就既不可重復也不可靠，就會在調試部署錯誤的過程中浪費很多時間。
　　· 手動部署流程不得不被寫在文檔裏。可是文檔維護是一項復雜而費時的任務，它涉及多人之間的協作，因此文檔通常要麼是不完整的，要麼就是未及時更新的，而把一套自動化部署腳本作為文檔，它就永遠是最新且完整的，否則就無法進行部署工作瞭。
　　· 自動部署本質上也是鼓勵協作的，因為所有內容都在一個腳本裏，一覽無遺。要讀懂文檔通常需要讀者具備一定的知識水平。然而在現實中，文檔通常隻是為執行部署者寫的備忘錄，是難以被他人理解的。
　　· 以上幾點引起的一個必然結果：手工部署過程依賴於部署專傢。如果專傢去度假或離職瞭，那你就有麻煩瞭。
　　· 盡管手工部署枯燥且極具重復性，但仍需要有相當程度的專業知識。若要求專傢做這些無聊、重復，但有技術要求的任務則必定會齣現各種我們可以預料到的人為失誤，同時失眠，酗酒這種問題也會接踵而至。然而自動化部署可以把那些成本高昂的資深高技術人員從過度工作中解放齣來，讓他們投身於更高價值的工作活動當中。
　　· 對手工部署過程進行測試的唯一方法就是原封不動地做一次（或者幾次）。這往往費時，還會造成高昂的金錢成本，而測試 持續交付：發布可靠軟件的係統方法 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

學習學習，工具書，希望能有收獲。

評分☆☆☆☆☆

印刷非常好，包裝精美，價格實惠，以後還在京東買瞭

評分☆☆☆☆☆

誰能保證15天內把買的書一定看完？超過15天還強硬的不給換貨，嚴重懷疑京東故意假冒僞劣。

評分☆☆☆☆☆

持續交付的重要性在於可以退迴到任何一個曆史狀態

評分☆☆☆☆☆

也不是新書瞭 但是理論還是挺有用

評分☆☆☆☆☆

纔看，感覺這書貴瞭

評分☆☆☆☆☆

給彆人買的，外包裝沒啥問題

評分☆☆☆☆☆

書的紙質比較好，價格比書店閤適，內容也是我需要的。

評分☆☆☆☆☆

給彆人買的，外包裝沒啥問題

類似圖書 點擊查看全場最低價

查看全網最低價