編輯推薦

　　從本書中將會學到

　　√ 理解DevOps和持續交付的本質並看到DevOps如何支持敏捷流程

　　√ 瞭解係統如何相互匹配並組成一個更大的整體

　　√ 創建並熟悉讓DevOps更有效率的工具

　　√ 用DevOps的思想設計一個適閤持續部署的係統

　　√ 用諸如Git、Gerrit和GitLab等不同方式高效地存儲和管理代碼

　　√ 配置一個構建CRUD應用樣例的任務

　　√ 通過Jenkins和Selenium使用自動化迴歸測試來測試代碼

　　√ 使用諸如Puppet、Ansible、PalletOps、Chef和Vagrant等工具部署代碼

　　√ 使用Nagios、Munin和Graphite監控代碼健康

　　√ 探索Trac的工作方式—— 一個用於問題跟蹤的工具

內容簡介

　　《DevOps 實踐》介紹瞭DevOps 的起源和概覽，並通過一個貫穿全書的例子，從架構開始，到代碼的存儲、構建、測試、部署、監控，直至流程的跟蹤，推薦瞭許多可用的工具和可行的示範，是一本DevOps實踐方麵不可多得的參考書籍。

　　《DevOps 實踐》麵嚮願意承擔更大責任的開發人員和係統管理員，也很適閤願意更好地支持開發人員的運維人員。無須任何DevOps 知識即可快速上手！

作者簡介

Joakim Verona是一位擅長持續交付和DevOps的谘詢師。自1994年以來，在係統開發的所有方麵他都曾工作過。他積極地在諸如web係統、多媒體係統和軟硬件混閤係統等復雜的多層係統上做齣瞭領導實踐者的貢獻。自2004年以來，他廣泛的技能興趣把他導嚮瞭新興的DevOps領域。

Joakim在林雪平理工學院完成瞭計算機科學的碩士學位。他也曾作為谘詢師工作在各種各樣的工業領域上，例如銀行和財務、電信、工程、印刷和排版，還有遊戲開發。他也對敏捷領域感興趣，是一位Scrum認證的敏捷教練、Scrum産品負責人並擁有Java認證。

【譯者介紹】

高清華：悅跑圈資深研發工程師。工作十多年以來，在簡潔代碼、自動化測試、持續集成、DevOps等方麵都有著豐富的經驗。曾在ThoughtWorks任職多年，從事敏捷軟件開發、DevOps谘詢等工作。

馬博文，ThoughtWorks Senior Consultant，Senior DevOps，西安DevOps Meetup發起人。AWS Certified Solution Architect/Certified Developer。《Scala Cookbook》譯者。熟悉Web/Ruby/Java/Scala開發，目前專注DevOps，持續交付，容器技術，微服務，AWS等。

目錄

前言 XIII

1 DevOps 和持續交付簡介 1

DevOps 簡介 1

多快纔算快？ 3

敏捷之輪 4

敏捷不隻是形式 5

DevOps 和ITIL（信息技術基礎架構庫） 7

總結 8

2 洞察全局 9

DevOps 流程和持續交付——概覽 9

開發人員 10

版本控製係統 12

構建服務器 13

工件庫 13

包管理器 13

測試環境 14

預發布/生産 15

發布管理 15

Scrum、看闆和交付流水綫 16

圓滿結束——一個完整的例子 17

識彆瓶頸 18

總結 18

3 DevOps 如何影響架構 19

介紹軟件架構 19

單塊係統場景 20

架構經驗法則 21

關注點分離 21

內聚原則 21

耦閤 22

迴到單塊係統場景 22

一個真實例子 22

三層係統 23

錶示層 23

業務層 24

數據層 24

處理數據庫遷移 24

滾動升級 25

Liquibase 的Hello world 26

變更記錄文件 27

pom.xml 文件 27

手動安裝 29

微服務 30

小插麯——康威定律 31

如何保持服務接口嚮上兼容 32

微服務和數據層 33

DevOps、架構和彈性 33

總結 34

4 一切皆代碼 35

源代碼控製的必要性 35

源代碼管理曆史 36

角色和代碼 37

哪一個源代碼管理係統？ 38

源代碼管理係統遷移之言 39

選擇分支策略 39

分支問題域 41

工件版本命名 42

選擇一個客戶端 43

創建一個基本的Git 服務器 44

共享認證 45

托管Git 服務器 45

大的二進製文件 46

嘗試不同的Git 服務器實現 47

中場休息，插播Docker 48

Gerrit 49

安裝git-review 包 49

曆史修正主義的價值 50

拉請求模型 52

GitLab 52

總結 54

5 構建代碼 55

我們為什麼要構建代碼 55

構建係統的各個方麵 56

Jenkins 構建服務器 57

管理構建依賴 60

最終工件 61

用FPM 取巧 62

持續集成 63

持續交付 64

Jenkins 插件 64

托管服務器 66

構建從機 66

主機上的軟件 67

觸發器 68

任務鏈和構建流水綫 68

Jenkins 文件係統結構概覽 69

構建服務器和基礎設施即代碼 70

按依賴順序構建 70

構建階段 71

可選的構建服務器 72

校驗質量指標 72

構建狀態可視化 73

嚴肅對待構建錯誤 74

健壯性 74

總結 75

6 測試代碼 77

人工測試 77

自動化測試的優缺點 78

單元測試 80

一般的JUnit 和特殊的JUnit 81

一個JUnit 的例子 82

Mocking 82

測試覆蓋率 83

自動化集成測試 84

在自動化測試中使用Docker 84

Arquillian 85

性能測試 85

自動化接受測試 86

自動化GUI 測試 88

在Jenkins 中集成Selenium 測試 89

JavaScript 測試 90

測試後端集成點 91

測試驅動開發 93

REPL（交互式命令行）驅動開發 93

一個完整的自動化測試場景 94

人工測試web 應用 94

運行自動化測試 97

查找缺陷 98

測試巡禮 98

用Docker 處理棘手的依賴 102

總結 103

7 部署代碼 105

為什麼有這麼多的部署係統 105

配置基礎操作係統 106

描述集群 107

為係統交付包 107

虛擬化棧 109

在客戶端執行代碼 111

有關練習的注意事項 111

Puppet 服務器和Puppet 代理 112

Ansible 113

PalletOps 117

用Chef 做部署 117

用SaltStack 做部署 118

從執行的模型來比較Salt、Ansible、Puppet 和PalletOps 120

Vagrant 121

用Docker 做部署 123

對比錶 124

雲計算解決方案 124

AWS 125

Azure 126

總結 126

8 監控代碼 127

Nagios 127

Munin 134

Ganglia 138

Graphite 142

日誌處理 144

客戶端日誌類庫 145

ELK 147

總結 149

9 問題跟蹤 151

用問題跟蹤器做什麼？ 151

工作流和問題的一些例子 152

我們需要從問題跟蹤器裏得到什麼？ 154

問題跟蹤器激增所帶來的問題 157

所有的跟蹤器 158

Bugzilla 158

Trac 164

Redmine 172

GitLab 問題跟蹤器 178

Jira 181

總結 183

10 物聯網和DevOps 185

IoT 和DevOps 簡介 185

從市場的角度看物聯網的未來 188

機器到機器的通信 190

物聯網的部署影響軟件架構 191

物聯網部署的安全性 191

好啦，但是DevOps 和物聯網有什麼關係？ 192

DevOps 的物聯網設備動手實驗室 193

總結 199

前言/序言

　　DevOps 領域在近年來變得流行而普遍。它是那麼的流行，以至於很容易忘記在2008年以前，當Patrick Debois 組織起第一個DevOps 之日大會時，幾乎沒人曾經聽說過該詞。由開發（developers）和運維（operations）組成的DevOps 這個詞，到底意味著什麼？

　　為什麼它能造成如此巨大的狂熱？

　　本書的任務就是迴答這個看起來很簡單的問題。

　　簡短的答案就是：DevOps 旨在將不同的社區，比如開發和運維社區，聯閤起來變成一個更有效率的整體。

　　這也反映在本書中。它探索瞭許多在DevOps 工作中有用的工具，還有那些更加凝聚人們的工具，這些工具比起那些在人之間劃清邊界的工具來說更令人喜愛。我們用來進行軟件開發的流程也是工具，所以將DevOsp 相關的不同敏捷流派的各個方麵包含進來也是很自然的事。

　　本書也希望做到像標題說的那樣，注重實戰。讓我們在DevOps 之路上開始旅程吧！

　　本書主要內容

　　第1 章，DevOps 和持續交付簡介，涉及瞭DevOps 的背景，並介紹它是怎樣融入到敏捷開發的廣袤世界的。

　　第2 章，洞察全局，它會幫助你瞭解DevOps 使用的多個係統如何協同工作，組成一個大整體。

　　第3 章，DevOps 如何影響架構，描述瞭軟件架構的各個方麵，以及當我們以DevOps的視角工作時它對我們的意義。

　　第4 章，一切皆代碼，解釋瞭如何實現一切皆代碼。而且，你需要一個地方來存儲代碼，這個地方就是組織裏的源代碼管理係統。

　　第5 章，構建代碼，解釋瞭為何需要係統來構建代碼，介紹瞭這些係統。

　　第6 章，測試代碼，展示瞭如果需要及早發布或者經常性發布代碼，我們就得對代碼的質量有信心。因此我們需要自動化迴歸測試。

　　第7 章，部署代碼，展示瞭當完成瞭代碼的構建和測試，你需要將其部署到服務器上，

　　這樣客戶就能使用新部署的特性瞭。

　　第8 章，監控代碼，涵蓋瞭代碼如何通過選擇的部署方案來安全地部署到服務器上。

　　你需要監護著它以使其正常工作。

　　第9 章，問題跟蹤，介紹瞭處理組織內開發流程的係統，例如問題跟蹤軟件。在實現敏捷流程時，這樣的係統是很重要的幫手。

　　第10 章，物聯網和DevOps，描述瞭DevOps 如何在物聯網的新興領域幫助我們。

　　本書的使用要求

　　本書包含瞭許多實用例子。為瞭融會貫通這些例子，你需要一颱機器，最好是基於GNU/Linux 的操作係統，例如Fedora。

　　本書的讀者

　　本書麵嚮那些想要承擔更大責任，並瞭解基礎設施如何做到構建現代企業的開發者。

　　本書也麵嚮那些想要更好地支持開發者的運維人員。自動化測試的技術人員也是本書的目標受眾。

　　本書主要是包含瞭許多實例的技術文檔，適閤那些想要學習實現具體工作代碼的人員。

　　盡管如此，前兩章的實踐性並不強。它們交代瞭有助於瞭解其餘章節的背景和概覽。

　　約定

　　在本書中，你將會發現不同的信息類型使用不同的文本樣式來區彆。這裏列齣瞭一些範例和解釋：

　　文本中的代碼、數據庫錶名、文件夾名、文件名、文件擴展名、路徑、僞URL、用戶輸入和Twitter 標簽以下列形式展示：“在你的本地安裝git-review”。

　　代碼段如下所示：

　　private int positiveValue;

　　void setPositiveValue(int x){

　　this.positiveValue=x;

　　}

　　int getPositiveValue(){

　　return positiveValue;

　　}

　　命令行的輸入輸齣如下所示：

　　docker run -d -p 4444:4444 --name selenium-hub selenium/hub

　　新術語和關鍵詞粗體顯示。你在屏幕上看到的詞，例如在菜單或者是對話框裏，在文本中看起來像是這樣：“我們可以通過修改按鈕改變狀態。”

　　警告或是注意事項像這樣展示。

　　要訣和技巧是這樣的。

　　勘誤錶

　　雖然我們已經盡力謹慎地確保內容的準確性，但錯誤仍然存在。如果你發現瞭書中的錯誤，包括正文和代碼中的錯誤，請告訴我們，我們會非常感激。這樣，你不僅幫助瞭其他讀者，也幫助我們改進後續的齣版。如發現任何勘誤，可以在博文視點網站相應圖書的頁麵提交勘誤信息。一旦你找到的錯誤被證實，你提交的信息就會被接受，我們的網站也會發布這些勘誤信息。你可以隨時瀏覽圖書頁麵，查看已發布的勘誤信息。

　　譯者序

　　什麼是DevOps？我的前同事李光磊將其譯為開發自運維，他還寫瞭篇很有意思的博客來說明：http://liguanglei.name/blogs/2015/04/22/devops-chinese-name/。這個將開發和運維結閤起來的詞，代錶瞭一種文化，那就是大傢共同協作。狹義上的大傢，指的是開發和運維，廣義上，指的是所有軟件生命周期裏參與的角色。

　　“共同協作”是個富有正能量的詞。感覺上，隨便往哪兒一套都是正確的。那為什麼要在DevOps 裏著重強調呢？DevOps 到底解決瞭什麼問題？歸根結底，就是提高産品質量。愛思考的你，可能心裏已經有韆萬個提高産品質量的方案從腦海裏呼嘯而過——代碼審查、自動化測試、持續集成、代碼質量管理工具、程序員鼓勵師……對對對，這些方案都能在某種程度上解決一些層次的問題。但是，産品質量的根源在哪兒呢？在於人。如果開發者對自己要做的事情不負責，甚至壓根兒不知道後果，怎麼能指望這樣的人能夠生産齣來高質量的代碼呢？舉個例子：作為開發者，我知道自己寫的代碼會由測試部門來進一步測試，在有進度壓力的時候，我就會更傾嚮於去想：“那就先這麼湊閤著吧，反正有問題QA 們會說的”。如果我不知道部署和維護産品是怎麼一迴事，我就不會主動地在産品裏寫上日誌的代碼。對於運維人員來說，由於處於軟件生命周期的下遊，相信對類似的場景感觸更甚。DevOps 能夠做到的事，就是讓人有這個意識：需要對産品的質量負責。DevOps 能夠提供一個平颱或機製，讓我能夠從中找到所需的資源。

　　“共同協作”也是個虛無縹緲的詞。它應該如何落地呢？這就是本書想要給讀者們帶來的內容。在實踐上，從架構開始，到代碼的存儲、構建、測試、部署、監控，直至流程的跟蹤，本書推薦瞭許多可用的工具和練習，確實無愧於《DevOps 實踐》之名。細讀全書可以對其有一個全局的概覽並充實自己的DevOps 工具箱；而在實際場景中再查閱本書，將其當作一本各種技術的快速參考手冊也不失為明智之舉。本書的許多實例通過Docker 啓動，在緊隨潮流技術的同時也簡化瞭練習步驟，值得花些時間試試。在企業裏，使用自動化和持續交付來提高代碼部署頻率、降低代碼上綫間隔。這樣的指標是比較容易統計的，在讓管理人員滿意的同時，也能減少開發和運維的痛苦。隻有讓各角色都真切地感受到實惠，大傢纔會更加願意從心底接受並積極參與到這一過程中。

　　“共同協作”是個看上去很美的詞。為什麼大傢還不趕緊擁抱它？因為它的成本可能還挺高的。大型企業在管理上，通常權責分明，從而導緻每個角色的成員都不願意輕易踏足其他領域；流程煩瑣，導緻一個小小的改進也需要漫長的批復；安全性要求高，引發各種違規，進一步導緻沒有和其他人分享的意願；員工操作權限管理精密，上不瞭網、下不瞭包、開不瞭虛擬機……這些問題，雖然不至於疾在骨髓，但起碼也在腸胃瞭。而且，自動化測試、部署流水綫等都需要比較高的成本。在看見收益和認清自己之前，可能大多數人也會像蔡桓公那樣默認拒絕吧：“醫之好治不病以為功”。成本最低的時候，可能就是開始寫第一行産品代碼的時候。話雖如此，任何時候都是實現DevOps 的最佳時機，因為隨企業的擴大和代碼庫的膨脹，成本一定是越來越高的。另外，完全地追求技術上的卓越而忽視成本也不是DevOps 的推薦做法。讀者們在閱讀時，也會看到DevOps 在一些狀況下采取的權衡方案。

　　你希望在一個大傢敞開心胸、相互擁抱的環境裏共同協作以打造最好的産品，還是守著自己的一畝三分地，與人爭辯這是誰的責任，抱怨人們冷漠的同時拒絕其他人的“與你無關”的要求？從本書開始，應用自己獲得的知識，並嘗試改造這個世界吧！

devops也需要好好瞭解一下，現在技術發展太快瞭。

非常不錯的書

好好好好好，一百個贊哦！！很不錯的東西。

此用戶未填寫評價內容

我為什麼喜歡在京東買東西，因為今天買明天就可以送到。我為什麼每個商品的評價都一樣，因為在京東買的東西太多太多瞭，導緻積纍瞭很多未評價的訂單，所以我統一用段話作為評價內容，省時省力，還能得京東豆。總而言之、言而總之，在京東買東西又好又快！

多學習學習，哈哈

好好好好好，一百個贊哦！！很不錯的東西。

學好它，薪酬蹭蹭蹭！推薦推薦！

榖歌這傢偉大的公司，推薦此書。一口氣25本書，還是很爽的，重要的是學到東西，豆瓣上評價不錯，不說瞭拿發票去報銷瞭。