商品簡介
作者簡介
【譯者介紹】
夏雪,曾擔任功能測試經理、敏捷教練,具有豐富的測試及測試管理經驗,在代碼靜態分析領域獲得過國家發明專利。現主要負責質量及過程改進管理,從事CI\/CD、DevOps的推進工作,並於2019年通過了EXIN DevOps Master認證。他非常樂於將國外的技術新聞和文章分享到國內,除本書外,另譯有《深入敏捷測試》。
名人/編輯推薦
2.書中提供的多個完整的示例項目為實驗、試驗計劃和全面部署提供了基礎。
本書適合想要採用持續交付的人員閱讀,無論你是否具有DevOps經驗。經理們將瞭解持續交付的核心流程、要求、收益和技術後果,而開發人員、管理員和架構師將獲得許多基本技能,以實現和管理流水線,並將持續交付順利集成到軟件架構和IT組織中。
●瞭解持續交付能夠解決的問題,以及如何解決這些問題
●建立基礎設施以實現*程度的軟件自動化
●利用虛擬化和PaaS雲解決方案
●使用Gradle、Maven和Jenkins實現構建自動化和持續集成
●使用SonarQube和存儲庫執行靜態代碼審查以存儲構建工件
●通過行為驅動設計建立自動化的圖形用戶界面(GUI)和文本化驗收測試
●通過容量測試確保適當的性能
●通過探索式測試檢查新功能和問題
●*程度地降低自動發佈軟件的風險
●使用Elasticsearch、Logstash、Kibana(ELK)和Graphite收集並分析指標和日誌
●將持續交付引入企業
●軟件架構促進持續交付新功能
目次
1.1 什麼是持續交付 2
1.2 為什麼軟件發佈如此複雜 2
1.2.1 持續集成帶來希望 2
1.2.2 過程緩慢且有風險 3
1.2.3 變快是有可能的 3
1.3 持續交付的價值 3
1.3.1 規律性 3
1.3.2 可追溯性 4
1.3.3 退化 4
1.4 持續交付的優勢 4
1.4.1 持續交付可加快上市速度 5
1.4.2 示例 5
1.4.3 實現特性並將其發佈到生產環境 5
1.4.4 下一個特性 5
1.4.5 持續交付能帶來競爭優勢 5
1.4.6 如果沒有持續交付 6
1.4.7 持續交付和精益創業 6
1.4.8 對開發過程的影響 6
1.4.9 最小化風險 7
1.4.10 更快的反饋和精益 9
1.5 持續交付流水線的生成及其結構 10
1.6 小結 12
第 2 章 提供基礎設施 13
2.1 概述 13
2.2 安裝腳本 14
2.3 Chef 16
2.3.1 對比Chef與Puppet 17
2.3.2 其他備選方案 18
2.3.3 技術基礎 18
2.3.4Chef Solo 23
2.3.5 Chef Solo總結 24
2.3.6 Knife和Chef Server 24
2.3.7 Chef Server總結 27
2.4 Vagrant 28
2.4.1 Chef和Vagrant實例 29
2.4.2 Vagrant總結 30
2.5 Docker 30
2.5.1 Docker解決方案 31
2.5.2 創建Docker容器 32
2.5.3 使用Docker運行示例應用程序 35
2.5.4 Docker和Vagrant 36
2.5.5 Docker Machine 38
2.5.6 Docker的複雜配置 39
2.5.7 Docker Compose 41
2.6 不可變的服務器 43
2.6.1 冪等性的缺點 43
2.6.2 不可變服務器和Docker 43
2.7 基礎設施即代碼 44
2.8 平臺即服務 45
2.9 數據和數據庫的處理 47
2.9.1 模式的處理 47
2.9.2 測試和主數據 48
2.10 小結 49
第二部分 持續交付流水線
第 3 章 構建自動化和持續集成 52
3.1 概述 52
3.2 構建自動化和構建工具 52
3.2.1 Java世界中的構建工具 53
3.2.2 Ant 54
3.2.3 Maven 54
3.2.4 Gradle 58
3.2.5 其他構建工具 60
3.2.6 選擇合適的工具 60
3.3 單元測試 61
3.3.1 編寫好的單元測試 62
3.3.2 測試驅動開發 64
3.3.3 整潔的代碼和軟件工藝 65
3.4 持續集成 65
3.4.1 Jenkins 66
3.4.2 持續集成基礎設施 70
3.4.3 結論 71
3.5 度量代碼質量 73
3.6 工件管理 76
3.6.1 集成到構建中 78
3.6.2 倉庫的高級特性 79
3.7 小結 80
第 4 章 驗收測試 81
4.1 概述 81
4.2 測試金字塔 82
4.3 什麼是驗收測試 84
4.3.1 自動化驗收測試 84
4.3.2 不僅僅是提升效率 84
4.3.3 手動測試 85
4.3.4 客戶 85
4.3.5 對比驗收測試與單元測試 86
4.3.6 測試環境 86
4.4 基於圖形用戶界面的驗收測試 87
4.4.1 圖形用戶界面測試的問題 87
4.4.2 針對脆弱的圖形用戶界面測試的抽象 87
4.4.3 使用Selenium實現自動化 88
4.4.4 WebDriver API 88
4.4.5 無須Web瀏覽器的測試:HtmlUnit 88
4.4.6 Selenium WebDriver API 88
4.4.7 Selenium IDE 88
4.4.8 自動化圖形用戶界面測試的問題 90
4.4.9 執行圖形用戶界面測試 90
4.4.10 將測試導出為代碼 90
4.4.11 手動修改測試用例 90
4.4.12 測試數據 91
4.4.13 Page對象 91
4.5 圖形用戶界面測試的替代工具 91
4.5.1 PhantomJS 92
4.5.2 Windmill 92
4.6 文本化驗收測試 93
4.6.1 行為驅動開發 93
4.6.2 不同的適配器 95
4.7 其他可選框架 96
4.8 驗收測試策略 97
4.8.1 合適的工具 97
4.8.2 快速反饋 97
4.8.3 測試覆蓋率 98
4.9 小結 98
第 5 章 容量測試 99
5.1 概述 99
5.2 如何進行容量測試 99
5.2.1 容量測試的目標 100
5.2.2 數據量與環境 100
5.2.3 只在實現結束時才進行性能測試嗎 100
5.2.4 容量測試 = 風險管理 100
5.2.5 用戶模擬 101
5.2.6 記錄性能需求 101
5.2.7 用於容量測試的硬件 101
5.2.8 雲和虛擬化 102
5.2.9 通過持續測試使風險最小化 102
5.2.10 容量測試是否明智 102
5.3 實現容量測試 103
5.4 使用Gatling實現容量測試 104
5.5 Gatling的替代工具 108
5.5.1 Grinder 108
5.5.2 Apache JMeter 108
5.5.3 Tsung 109
5.5.4 商業解決方案 109
5.6 小結 109
第 6 章 探索式測試 110
6.1 概述 110
6.2 為什麼要進行探索式測試 110
6.2.1 有時手動測試會更好 110
6.2.2 由客戶測試 111
6.2.3 非功能性需求的手動測試 111
6.3 該怎麼做 111
6.3.1 測試任務指南 112
6.3.2 自動化的環境 112
6.3.3 以展示為依據 112
6.3.4 示例:電子商務應用程序 112
6.3.5 Beta測試 112
6.3.6 基於會話的測試 113
6.4 小結 114
第 7 章 部署:在生產環境中發佈版本 115
7.1 概述 115
7.2 發佈和回滾 115
7.2.1 優點 116
7.2.2 缺點 116
7.3 前滾 116
7.3.1 優點 117
7.3.2 缺點 117
7.4 藍/綠部署 117
7.4.1 優點 118
7.4.2 缺點 118
7.5 金絲雀發佈 118
7.5.1 優點 119
7.5.2 缺點 119
7.6 持續部署 120
7.6.1 優點 120
7.6.2 缺點 121
7.7 虛擬化 121
7.8 Web應用程序之外 122
7.9 小結 123
第 8 章 運維 124
8.1 概述 124
8.2 運維中的挑戰 124
8.3 日誌文件 125
8.3.1 應該記錄什麼 126
8.3.2 處理日誌文件的工具 127
8.3.3 示例應用程序中的日誌記錄 128
8.4 示例應用程序的日誌分析 129
8.4.1 用Kibana做分析 131
8.4.2 ELK――可擴展性 132
8.5 用於日誌的其他技術 134
8.6 高級日誌技術 135
8.6.1 匿名化 135
8.6.2 性能 136
8.6.3 時間 136
8.6.4 運維數據庫 136
8.7 監控 136
8.8 Graphite指標 137
8.9 示例應用程序中的指標 138
8.10 其他監控解決方案 140
8.11 運維應用程序時的額外挑戰 141
8.11.1 腳本 141
8.11.2 客戶數據中心內的應用程序 141
8.12 小結 142
第三部分 持續交付的管理、組織和架構
第 9 章 引入持續交付 144
9.1 概述 144
9.2 從一開始就引入持續交付 144
9.3 價值流映射 145
9.3.1 描述事件序列的價值流映射 145
9.3.2 優化 145
9.4 其他優化措施 146
9.4.1 質量投資 146
9.4.2 成本 147
9.4.3 收益 147
9.4.4 不要在“紅色構建”上檢入 147
9.4.5 立即停止 148
9.4.6 “五個為什麼” 148
9.4.7 DevOps 149
9.5 小結 149
第 10 章 持續交付和DevOps 150
10.1 概述 150
10.2 什麼是DevOps 150
10.2.1 問題 150
10.2.2 客戶視角 151
10.2.3 先鋒:亞馬遜 151
10.2.4 DevOps 151
10.3 持續交付和DevOps 152
10.3.1 DevOps:不只是持續交付 153
10.3.2 個體責任和自組織 153
10.3.3 技術決策 154
10.3.4 減少集中控制 154
10.3.5 技術多元化 154
10.3.6 團隊間的交流 154
10.3.7 架構 155
10.4 沒有DevOps的持續交付 156
10.5 小結 157
第 11 章 持續交付、DevOps和軟件架構 158
11.1 概述 158
11.2 軟件架構 158
11.3 針對持續交付優化架構 160
11.4 接口 161
11.4.1 伯斯塔爾法則 162
11.4.2 容錯設計 162
11.4.3 狀態 163
11.5 數據庫 163
11.5.1 保持數據庫穩定 163
11.5.2 數據庫 = 組件 164
11.5.3 視圖和存儲過程 164
11.5.4 每個組件一個數據庫 165
11.5.5 NoSQL數據庫 165
11.6 微服務 165
11.6.1 微服務與持續交付 165
11.6.2 借助微服務引入持續交付 166
11.6.3 微服務需要持續交付 166
11.6.4 組織 166
11.7 新特性的處理 167
11.7.1 特性分支 167
11.7.2 特性開關 167
11.7.3 優點 167
11.7.4 特性開關的用例 168
11.7.5 缺點 168
11.8 小結 169
第 12 章 總結:收益是什麼 170
主題書展
更多主題書展
更多書展本週66折
您曾經瀏覽過的商品
購物須知
大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大,除封面破損、內頁脫落等較嚴重的狀態,其餘商品將正常出貨。
特別提醒:部分書籍附贈之內容(如音頻mp3或影片dvd等)已無實體光碟提供,需以QR CODE 連結至當地網站註冊“並通過驗證程序”,方可下載使用。
無現貨庫存之簡體書,將向海外調貨:
海外有庫存之書籍,等候約45個工作天;
海外無庫存之書籍,平均作業時間約60個工作天,然不保證確定可調到貨,尚請見諒。
為了保護您的權益,「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。
若要辦理退貨,請在商品鑑賞期內寄回,且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。