 |
VOOZH | about |
|
VOOZH | about |
這是DevOps的趨勢圖。DevOps這個概念大概是在2009年被提出來的，2010年有一些公司開始試點，之後DevOps的熱度持續增加，這是我們在谷歌搜索DevOps關鍵字得到的搜索量，這條曲線表示了DevOps熱度呈指數級增長。因此我預計2016年DevOps仍然會成為一個非常受關注的技術。
什麼是DevOps？
我們在試點DevOps的時候做了很多研究，也在網上做了很多搜索。比較普遍的說法是：DevOps是一種文化，用以打破開發、運維以及測試之間的工作壁壘。之所以會有壁壘是因為開發、測試、運維的工作職責、目的存在不一致性。比如開發的主要目的是趕緊實現業務級的新需求及功能，交給客戶使用，然後根據反饋信息繼續更新；運維的主要目的是生產必須快速、不能出問題，所以他們不是很喜歡「變化」，因為變化可能會帶來風險，隨之而來的就是各種問題，這是他們最不願意看到的。
如果站在他們各自的角度來看，這些考慮都很正確，但現在的市場要求所有研發人員的最終目的都是「幫助業務部門創造商業價值」，而不只是狹隘地滿足各自的目標。如何創造商業價值？充分滿足客戶的需求。客戶的需求是多變的，而且變化的速度很快，這就要求我們必須跟上他們的步伐，快速實現最新功能並交給客戶使用，如果一個系統很穩定但沒有人使用，那它一樣不能給我們帶來任何東西。
維基百科上對DevOps的解釋是：軟體開發人員和IT運維技術人員之間溝通合作的文化、趨勢或實踐。透過自動化（軟體繳付）的流程，來使得構建、測試、發布軟體能夠更加地快捷、頻繁和可靠。之前開發、測試、運維三者之間可能是獨立的，現在要求更緊密一點。一句話總結，DevOps就是：開發測（試）（運）維融一體，敏捷高效自動化。這也是我們對DevOps的定義和理解。
自2009年提出DevOps的概念起，很多公司都開始實施DevOps，國外比較著名的有Google、Facebook等，國內著名的有百度、華為、阿里、Flickr等，他們實施DevOps的結果是每天有10次部署，這是非常了不起的。
二、HPE IT在DevOps上的實踐
HPE IT部門在2014年年底的時候引入DevOps概念，2015年找了一些內部的敏捷項目做試點，2016年我們開始在400多個應用里推廣DevOps。1、引入DevOps的實際背景
既然要實踐要推廣，我們看一下目前的現狀。IT在開發的流程上使用敏捷已經很久了，所以可以看到，開發實際上採用了敏捷的疊代方法，每個衝刺都會產出一個可發布的產品。到了運維這邊，我們不得不遵循企業發布規則：每三個月一次發布窗口，我們就必須等待。根據應用的技術不同，有不同的運維團隊來幫助你做生產環境的部署和監控，所以我們得找到相應的運維團隊，提前7天提交一個rfc。這些流程做完之後，運維團隊開始部署，這時要寫一個「部署文檔」告訴他怎麼上傳到伺服器，把哪個文件刪掉、哪個文件備份等，我看到最大的可能有十幾頁，很多時候運維人員要管很多項目，部署又有問題。整個流程非常繁瑣，敏捷在實現在開發中的運用，但在運維中仍然不足。最後我們看到「部署」變成最後一公里，最後一公里如果沒法做到「敏捷」的話，前面的「敏捷」可能就白做了。
2、DevOps持續交付、持續部署
為了解決這些問題，我們提出了一個DevOps的方案，通過持續交付和持續部署來實現。持續交付和持續部署大體上包括了4個部分：1.開發和開發相關的；2.QA測試相關；3.用戶測試相關；4.生產運維相關。通過整個的DevOps持續集成、持續交付把開發、測試、運維三者都包括其中。
開發環節的持續集成
我們強調每一個開發人員做的任何修改，必須得在本地通過新功能的單元測試。通過了新功能的單元測試後會做整合，然後提交到代碼倉庫，一旦提交代碼到代碼倉庫，我們的伺服器會自動觸發，做自動化構建和比較全面的單元測試，然後再做部署到itg上面，如果這個新的代碼通過了itg的測試就會顯示時綠色的，沒通過會顯示是紅色的。
有的時候開發很著急，不斷寫新代碼希望做得快一些，不注意細節，QA就覺得很難理解，有的時候甚至構建不起來，提交過來也沒辦法部署。舉個例子，我們要求所有代碼都是小寫，有一次我們的開發用了第三方的一些庫文件，而這個第三方的庫文件中間會有大寫的字母，這些大寫的字母出現在配置文件中，到部署時就可能導致QA環境出錯。因為我們的QA環境是Liunx的系統，對大小寫比較敏感。
開發經常說：「在我這邊是好的，是你的問題，不是我的問題。」為了避免這樣的狀況出現，我們要求必須得在itg上做測試，這個itg和生產環境比較類似，都是Liunx。
代碼分支策略：單分支結構
接下來介紹一個我們的分支策略。我們的代碼分支策略叫單分支結構，這樣的好處有：
（1）如果在開發時有太多的分支，最後合併會很麻煩。每一次合併分支開發人員都要花少則半個小時到一個小時，多則半天到一天的時間，合併好以後測試人員再做回歸測試。整個流程下來，一天就過去了，所以我們不太贊成有太多的分支。
（2）我們持續集成的服務是監控主幹的，主幹上有任何代碼提交都會發現。如果我們不去看這些分支，這些分支就不做持續集成，這樣的風險很大。這是我們分支的策略，我們要求每個開發每天至少要提交一次代碼到代碼倉庫。每天提交、每天做測試就不會那麼容易出現問題；如果很久才做測試的話不僅會發現很多問題，而且修改起來非常費時間。我們可以做到大概每天1.5次/人的代碼提交。
測試環節的持續集成測試環節主要是新功能和非功能的回歸測試。每個地方都有一個圈子，圈上面有剪頭，表示持續循環地做，而不是只做一次，所以我們叫「持續做測試」。我們儘量使用和生產環境類似的作業系統、數據等來做測試，這樣回歸測試做完之後我們就很有信心，因為測試環境和生產環境一致，測試完之後放到生產環境中就很放心了。測試中我們在Shift Letf上的關注有幾點：
（1）需求給了開發，開發完之後給測試，大家目的不一致互相不買帳，討論來討論去大家開始扯皮，到底是開發與測試對需求的理解不一樣還是什麼？再把BA等拉進來討論，非常浪費時間，這不是我們希望看到的。我們希望看到的是整個自動的流程就過去了，這樣才可以達到敏捷和快速交付的目的。所以我們會在做需求的時候就讓測試參與進來。
（2）要把測試儘早來做。我們之前在做敏捷的時候，開發可以做到敏捷，然後交給測試，但測試不一定能夠馬上就進行，因為還得部署，得找人部署到QA系統。原來都是手工部署，比如我們的前端有5個模塊，後端有1個模塊，都部署完手工做要將近20-30分鐘。
在開始大家工作都不是很忙的時候可以讓開發的人幫忙部署，而在最後幾天大家都非常忙，開發有很多需要修改的地方，沒有時間做其他的事情，所以我們必須採用自動化部署。我們在做「持續集成」的時候有部署的腳本，做進一步的加工和改善，讓他直接部署到這個環境。這樣QA可以直接選擇QA環境部署，也可以在任何一個缺陷提交上來的時候馬上做測試。
持續回歸測試方面我們引入的另外一個概念叫「持續回歸」。如果你最後做回歸測試的話會發現很多缺陷，這些缺陷再讓開發修改，時間上會有問題。其實這也是Shift Letf的概念之一，儘早做回歸測試並持續做好。我們差不多兩天左右會做一次回歸測試，持續這麼做的好處在於：兩周後再做最後一輪的回歸測試就相對簡單多了，因為這個時候很多回歸上的問題很早就被發現並修改了。
自動化測試自動化測試非常重要，因為持續化的部署和回歸測試的頻度非常高，持續化的回歸兩天一次，如果讓QA人員做手工測試他們肯定會說：「兩天一次怎麼做得完？」這就需要進行自動化測試。
每次自動部署到QA環節後，我們的「持續部署伺服器」會調自動化測試的框架，其次是關注在穩定的功能模塊。我不想去自動化所有的東西，這不太現實，我不希望我們的測試花太多時間在維護測試腳本。
非功能的也要關注，以前開發和測試更多關注功能性的需求，而非功能性的需求運維關注得比較多。很多時候會聽到客戶關於性能的抱怨：我登陸一兩分鐘都登陸不進去。DevOps是打破壁壘，融合各個teams。所以開發和測試一定要更多地關注非功能點，關注運維對於性能安全方面的要求。
運維環節的持續集成
准生產環境
我們會給用戶做「驗收測試」，同樣要保證他的環境和生產環境比較一致，比如數據的一致、部署文件的一致。從持續集成開始，文件部署到ITG還是QA還是STG還是生產環境？部署腳本只有一個，我們只給他一個參數，說要什麼目標，然後他去做部署。這麼做的好處是什麼呢？其實這個文件本身是要被測試的，否則自動部署到生產環境會很危險。通過不斷地測試，包括QA環境每天都要部署，這麼多次部署確定這個腳本沒有問題。所有的東西都會放在代碼倉庫里，包括腳本，部署的腳本也是從代碼倉庫里實時拿過來再做部署，這是准生產環境。
持續部署部署到生產環境，我們面臨的問題很複雜，要做很多手工的操作。如何改善這最後一公里呢？我們和運維人員商量：你們能不能不要在我每次部署的時候跟我說「你要完成這個，要完成那個」，而是在完成之前我們就開始合作，我部署的過程和你team一起做。因為你對部署是有要求的，你確認這個部署文件是OK的、符合生產環境中對「安全」「穩定」各方面的要求，包括在部署之前我們必須要做的一些安全測試、性能測試，都在我們的部署文件里被自動觸發，一旦你認可了，我們就用這個部署文件去部署，然後所有的日誌都會被記錄下來。這樣做的好處是打通了自動化，不用再依賴於運維人員手工部署。
在生產環境中我們會有監控，整個監控體系分為三層：業務監控、應用監控、系統監控。可以看到，我們其實在開發和部署的流程里已經把運維包含進來了。包括我們現在用的更多的雲服務，用了「雲」以後把運維的一些基本服務給了雲商，比如我們用亞馬遜或微軟的雲，如果有問題他會給我們發郵件提醒。通過DevOps這樣的流程我們可以做到把原來高風險的發布變成每次發布一點，但發布的頻率很高。業務人員也能接受，有的時候他們要做一些緊急的業務更改，在之前得到的答覆是：等三個月，三個月之後給你，這樣他肯定不願意，因為緊急上線；現在得到的答覆是：沒關係，兩個禮拜以後就可以給你，業務人員更願意接受後者，因為可以保證生產的穩定，保證開發的順暢。這就是DevOps能夠幫助我們解決的問題，減少發布的風險，全流程自動化順暢。
三、DevOps帶來的好處這是DevOps在敏捷方面的實施。敏捷大家很熟悉，比如四周一個敏捷項目：第一周做敏捷的疊代、計劃會議，周一開始做了，開完會之後開發和測試以及po或ba一起再討論一下，周四開發，開發到第三周結束，接下來是回歸、驗收測試、發布上線這樣的流程。敏捷通常最後我們會部署在stg給PO做Demo，為了儘可能早的發現問題，我們會在第二周的周四或第三周的周三部署已完成的部分到STG，有的時候業務人員提需求的時候想得也不是很明白，等你做完之後他可能又會覺得不是很好，所以就要儘早測試，有問題儘早改，最後我們發布到生產環境做冒煙測試，然後這裡再創建一個新的分支。所有的測試都是循環使用，所有的代碼都放在代碼倉庫里。
四、持續部署Pipeline和工具、DevOps業界工具鏈本文由壹佰案例技術編輯根據HPE & msup技術開放日講師的分享內容整理後原創首發，轉載或節選內容前需獲授權。同時，也歡迎更多企業、社區與TOP100公眾帳號展開內容合作，更歡迎您成為原創作者。更多內容合作請添加微信EF0815，輸出你的技術品牌！
