DevOps系列 | 你在的組織對DevOps知道多少|結尾有彩蛋如果你或者你的公司組織正在尋求向DevOps過渡，我建議可以多注重洞察力方面的戰略性前瞻思維，起碼它可以協助構建敏捷實踐和自動化過程。

現在的IT部門是企業能夠快速響應市場和得到競爭優勢的主要動力。IT專人開始改變自己在行業中管理專案的方式方法，而管理方法本身也在不斷改進。試想一下，當下網際網路正在顛覆一個個行業，我們試著從高層角度看這件事，作為資訊行業的領導者/追隨者，IT專案管理方式不強大怎麼行？

DevOps發起於發達國家，它們的網際網路起步比我們早。在此理論的影響下，敏捷性和持續交付成了軟體開發和測試領域的新鮮熱門話題，因為它描繪了一個有效應對現代工作流程的一些核心原則和流程。

DevOps全貌沒有非黑即白立馬呈現，想要落地就要接受一個逐步進化的步驟和階段。換句話說，世上最不會改變的就是改變，DevOps不是老闆一拍腦袋就能很快落地的事，在實施過程中的各種具體執行也不存在一勞永逸。翻譯成IT術語，DevOps透過簡化組織的工作方式，分解組織孤島（部門牆）來實現，有效促成合作。

敏捷的4個階段

現代軟體交付鏈涉及許多重要工具和流程，許多組織正在打怪升級，不斷進入DevOps下一階段。一口雖然吃不了胖子，但DevOps內有4個主要的敏捷階段可以作為一定的參考標準。

瀑布流：瀑布交付是很多企業在用的交付模式，其內涵包括一些手動過程，比如測試。程式碼按照特定節奏編寫，測試和交付。所有的整體團隊，包括開發人員，運營和質量保證，都在孤立地運作，很少合作。開始敏捷：一般來說，有一定程度敏捷的組織正處於瀑布的快速階段。但是由於靈活性，重定位或修復bug的機會有限，最終產品說不定……咳咳，我們往下說。實際操作階段，GitHub上一大堆工具是很有可能為工作流程帶來一定程度上的自動化和可擴充套件性。不過即便在此基礎上又有了一些自動化方面的測試，但基礎流程決定約束仍然存在，比如一些並行測試。持續整合：DevOps跑到一定階段的標誌是用了諸如Jenkins，CircleCI和TeamCity等持續整合平臺，這些工具對構建自動化大有益處。這裡確定交付模式存在的深層次問題，把開發運營角色職能匯聚起來，使得快速診斷和快速解決得到落實，又沒有佔用額外資源。持續交付：走到這裡，DevOps基本已經落地成型。實現持續交付的組織採用了近乎全自動化的開發流程，甚至於包括高頻而精確的自動化測試。此外，開發，運營和QA團隊也已形成一股戰鬥力，不斷地相互同步。這個階段調整業務需求、IT專案、開發團隊和IT運營人員等曾經比較頭疼的大動作都變得更加順暢，以便持續提供新的應用版本。提高測試敏捷性

透過採用開發，交付和產品相關的工具開啟DevOps落地的組織很可能會發現自己在敏捷方面受到高效自動化測試流程的限制。我知道說說很容易，但破局之道確實就是提高測試效率。

先前的DevOps工具和方法提高了部分測試效率，比如自動測試、雲測試、並行測試、左轉測試…不過這些使測試更有效率以提高敏捷性的策略迄今沒成為DevOps對話的核心部分，但它們構成了簡單，低成本的增長更靈活的方法，以便實現全面持續交付的目標。

為什麼自動測試對DevOps來說是非常重要的

自動化測試的作用本質在實現持續交付方面與其他DevOps工具區別開來。當目標是實現全面的敏捷性時，自動化測試的重要性就凸顯了。

在印象裡，開發Web應用的企業在過去很多年就充分利用到受DevOps啟發的工具和技術了。從GitHub倉庫，到Jenkins，它們已經實現了幾種方法來構建部分的自動化流程。這些摸爬滾打探索出來的流程很大程度上能確保開發可以輕鬆加愉快的與QA和運維溝通對話。換個角度，部分這些特定的企業已經很大程度上吸收了DevOps文化。

然而熟歸熟，該指出的短處還是要指出，它們缺乏自動測試的DevOps資源，還是赤手空拳打天下。雖然測試可以指令碼化，但大多數測試都是在臨時搭建的基礎上進行，而團隊還沒有在構建過程中把自動化測試囊括進去。

缺乏完整的測試自動化過程意味著產出高頻且可靠質量的應用依舊（相對）困難。此外，這很有可能會擾亂組織已經執行的其他新變更，xue開發和交付的管道價值。雖然這些變化已經優化了開發和部署，但沒有實際的自動測試導致連續交付依然困難。因此，即便工作流程更敏捷了，但還是沒達到持續交付的效果。

此階段並非對持續交付就沒什麼價值，既然缺一環，那就能理解它的價值在鋪墊，繼續DevOps下一步的鋪墊。使自動化測試成為持續整合工作流程的一部分的工具，這對現有流程的敏捷性幫助就大了。

企業文化與DevOps文化如何共同發展

DevOps你也可以看成是一種交付心態（哈哈），一種人人為我、我為人人的協作心態。團隊每個人都肩負業務指標，協作搞定需求，共同思考開發，構建，測試並部署到整合環境。跨團隊合作，創造性挑戰和勇氣，隨著越來越多的迭代進步，都包含DevOps概念。

DevOps是高效軟體交付的核心部分。大多數超出使用者預期的公司，他們的IT模式早已不是你我能隨便趕超的樣子，他們都在做最好的工作，深諳DevOps之道。拋開這種大神級文明，我們為了達到持續交付實質性階段並儘可能全面敏捷，要做的不單是用幾個DevOps工具，也可以用DevOps涉及的語言。

組織需要徹底改革在瀑布發展時期建立的做法，讓工作流程完全敏捷、完整的DevOps落地，才更貼近你我可能都說不太清楚的DevOps理念。開始工具因公司而異，但有一些東西是崗位上就要有的覺悟：運維方面，請構建屬於自己的自動化；測試人員，請構建自己的自動化測試；開發不是不需要考慮，能協助就是最大的幸福，畢竟聽說你們玩OT都是玩的最高階。

我一直在做DevOps 方面的工作，談談我的體會

文化認同，公司內部如果沒有DevOps文化認同，很難開展；其實DevOps 不是技術的問題，而是流程的問題需要有人帶頭推廣實踐，另外需要配合敏捷開發一起，如果你的公司連敏捷開發都沒用，就不要提DevOps 了關鍵是用好DevOps, 而不是一味的搭建一套所以的持續交付環境，其實最後使用成本是很高的，因為你必須要依賴於一個懂devops 運維的團隊，但是這樣又引入一個問題， 就是devops團隊並不清楚 業務開發的結構，如果快速構建這個流程，溝通成本很高還有不同技術棧，如果快速複用，畢竟對於一般開發人員，他們不懂如何寫pipeline ,他們也不關心 什麼部署環境什麼樣，他們應該foucus 自己的業務開發所以這引入最後一個問題， 最好的DevOps 就是 “根據不同的技術棧，開發可以選擇不同的流水線模板，快速的建立DevOps 流水線”， 但是這樣的開發成本是很高的。。你需要了解DevOps 工具，需要對 現有的 CI/CD進行封裝。。。當然這是最高階的玩法。。

對於剛開始實踐的公司，可以搭建一套開源的CI/CD 先玩起來。DevOps 落地 “落的好”確實很不容易， 至少我的實踐中，我也沒找到滿意的答案。。。太難了。不全是技術問題，更多是 上層又沒有決心，做這個短期內 無法收益的事情，但是對未來收益很大的事情。。

下面是我過去寫的一篇文章

持續整合的反模式 （原文 http://gigix.thoughtworkers.org/2017/5/2/stack-management-and-tech-radar/）

最需要被點名批評的現象莫過於“持續整合劇場”了：

很多開發者只是簡單的搭建了持續整合伺服器就以為在做“持續整合”，但他們實際上會遺失持續整合的關鍵優點而導致失敗。常見的失敗模式包括：雖然在一個共享的主分支上執行持續整合，但是程式碼提交不頻繁，所以整合並沒有真正的“持續”。以及在一個測試覆蓋率不足，甚至是長期狀態為紅的情況下進行構建；或者在功能分支上執行持續整合，這會導致持續隔離。

簡而言之，這些團隊並沒有真正體會到持續整合的好處，而是為了完成上級的任務而演一場“我們在持續整合”的戲——這也正是這個反模式的名字由來。過去十年中，我們在眾多剛開始實施持續整合的企業見過這一幕。領導認識到持續整合的好處，但是推行成了個大問題：推輕了，下面團隊不願動，技術問題解決不了；推重了，下面團隊來個上有政策下有對策，領導想看什麼就給你演什麼——持續整合劇場就此落成。比如說你見過一個表面看起來一直是綠色但是背後連編譯都不敢跑的持續整合嗎？ 我見過。真是一場好戲。

為了解決持續整合演戲的問題，一些規模較大的企業開始建設持續整合中心。想法很符合直覺：既然團隊自己做持續整合有技術困難、還有可能變成演戲，那麼我就組建一支團隊專門幫他們一個個把持續整合跑通、幫他們管理持續整合伺服器，持續整合的執行和統計資料都在這個中央團隊手裡，下面的團隊總沒辦法演戲了吧？於是，他們又遭遇了第二個持續整合反模式：“所有團隊共用一個持續整合例項”。

那些必須使用中心化持續整合伺服器的交付團隊，常常依賴中心的團隊去完成小的配置任務，或者在共享的基礎設定和工具中排查問題，這給他們在進度上帶來長時間的滯後。

這次是康威定律帶來的困難：如果每個團隊使用的技術棧配置不同、技術棧配置和管理的職責仍然在每個團隊中，那麼技術棧演進與持續整合的演進就難免出現節拍不一致。於是管理著持續整合中心的中央團隊開始疲於奔命，幫一個個專案團隊修持續整合，而專案團隊還感到沒有得到足夠的支援。

第三個反模式是“企業級整合測試環境”，這也是很多組織建設持續整合中心的初衷之一：由於能執行完整端到端測試的環境稀缺，各個團隊的整合測試無論如何也必須在一個瓶頸處統一排程，所以中心化管理持續整合也就順理成章。然而，

這些企業整合測試環境通常稱為 SIT 或預生產環境）是當下持續交付常見的瓶頸。環境本身很脆弱而且維護成本很高，而這些環境通常存在一些需要由單獨的環境管理團隊手動配置的元件。在預生產環境的測試給出的反饋慢且不可靠，而且會重複測試那些在隔離的元件上已經測過的功能。

我的體會

對於上面第一個情景，很多時候我們以為有了工具就是持續整合，但是往往那些持續整合並不是那麼完美，至少在我看到都是“hardcode”, 可移植性差，不能複用，維護成本高，下一個接手的人需要花時間瞭解上一個人做的“CI/CD”；因為在一些團隊裡，並不是很重視這個，認為CI/CD僅僅是個輔助的東西，當然這樣跟國內專案的開發週期有關，有時候專案很小，客戶催的很急，哪有時間去最佳化那麼好，能用起來再說。當下一個專案來的時候，同樣的技術棧的專案還要重新來過一次。畢竟對於開發團隊來說，CI/CD是另外一個領域的東西，雖然入門簡單（按照網上的教程一個很簡單demo就搞定了），但是裡面的思想和業務場景需要一個個業務場景的積累，如何最佳化，如何標準化複用，這並不是簡單的事情，其實這也是DevOps要解決的一個個痛點。那麼我們建個專業的團隊做這個事情吧，就是第二個場景提到的事情，其實這也是我目前正在進行中的場景，但是隨著業務開展，嚴格意義上還沒有人用，我們就發現你搞出來了，不見得有人會用，不同的業務，不同的技術棧，你需要和Dev團隊密切溝通，需要DevOps團隊有廣闊的技術視野，如果服務眾多個不同業務團隊，你可能會發現自己被動的成為了“那個業務專案的一員”；另外溝通的成本其實也不低，想法是好的有個專業的團隊，但是落地不是那麼容易，這不是一個人，一個團隊能解決的問題。那麼如何解決這個困境？ 我認為需要企業自上而下，推廣這種文化，可以從一個專案開始做推廣，小步快跑，將“標準化規則”慢慢建立起來，比如分支的管理，依賴管理，CI/CD與不同技術棧的整合標準化，環境問題（內部環境,線上環境），最後衍生出來一個標準化的CI/CD平臺。最後的場景是，Dev團隊只關注於業務，他們只需要基於一個CI/CD模板，填寫必要的環境引數等，剩下的事情不需要他們管，對於他們是透明的，他們只需要產出是什麼，比如倉庫，郵件通知等等。所有的”快速複用，持續交付”都是基於大家形成的一個標準流程，沒有標準，就沒有”複用”，就沒有快速的迭代，最後還是”半人工”的低效工作。