1. <legend id="jwpzh"></legend>

    2. <optgroup id="jwpzh"></optgroup>

      <optgroup id="jwpzh"></optgroup>
      1. 回到主頁

        干貨 | 使持續交付成為可能,構建自動化應用發布

        · 操作指南

        時間:凌晨3點 地點:深圳科技園 職業:運維汪

        凌晨2:50,睡眼朦朧的我從手機鈴聲中醒來,還有10分鐘,就要上線2.0版本,

        看著研發丟過來的滿滿三頁的操作文檔,心中有點淡淡的惆悵,又到上線新版本的時候了。

        凌晨3:30,操作文檔已經執行到了第22條,還有5條,心中默默有點小激動,仿佛全世界都在我的手上,

        機械鍵盤的音符已經匯聚成一曲交響曲, 上傳包,解壓,拷貝文件,所有的操作如絲般順滑。

        凌晨3:35,最后一步了,深呼吸,仿佛已經可以看到凌晨四點鐘的南山科技園, 當回車鍵按下的一瞬間,執行失敗,瞬間懵圈,

        開始漫長的排查過程,確認上面的每一步操作是否正確。

        凌晨4:30,終于找到原因了,第18條操作文檔,有個舊的目錄沒有刪除,終于松了一口氣,極度疲憊的狀態下,敲下了這些命令,

        敲下去的一瞬間,發現所有的命令都執行不了了,仔細一下原來刪除了根目錄,所有的數據都沒有了,頓時世界安靜了。

        你是否也經歷過類似的手工發布過程?在持續交付中有三類部署反模式。

        (*本篇部分內容來源于了《持續交付:通過自動化構建、測試、部署流水線實現可靠的軟件發布 》一書)

        第一類:手工部署軟件

        對于現在的應用程序來說,無論規模大小,其部署過程都比較復雜,而且包含很多非常靈活的部分。許多組織都使用手工方式來發布軟件。也就是說部署應用程序所需的這些步驟是獨立的原子操作,且由某個人或某個小組來分別執行。每個步驟里都有一些需要人為判斷的事情,因此很容易發生人為錯誤。即便不是這樣,這些步驟的執行順序和時機的不同也會導致結果的差異性。而這種差異性很可能給我們帶來不良結果。

        這種反模式的特征是:

        • 有一份非常詳盡的文檔,該文檔描述了執行步驟及每個步驟中易出錯的地方。

        • 以手工測試的方式來確認該應用程序是否正確運行了。

        • 經常發生這樣的情形:在發布當天開發團隊會接到電話,被通知部署出錯了,以及出錯的現象是怎樣的。

        • 在發布時,常常會修正一些在執行過程中發現的問題。

        • 如果是集群環境部署,常常發現在集群中各環境的配置都不相同,比如應用服務器的連接池設置不同,文件系統有不同目錄結構等。

        • 整個發布過程需要較長的時間。

        • 發布結果不可預測,常常不得不回滾或遇到不可預見的問題。

        • 發布之后凌晨兩點還睡眼惺忪地坐在顯示器前,絞盡腦汁想讓剛剛部署的應用程序正常工作。

        相反,隨著時間的推移,部署應該走向完全自動化。即對于那些負責將應用程序部署到開發環境、測試環境或生產環境的人來說,應該只需要做兩件事:(1)挑選版本及需要部署的環境,(2)按一下“部署”按鈕。對于套裝軟件的發布來說,還應該有一個創建安裝程序的自動化過程。


        我們將在本書中討論很多自動化問題。當然,并不是所有的人都能接受這個想法。那么,我們先來解釋一下,我們為什么把自動化部署看作是一個必不可少的目標。

        • 如果部署過程沒有完全自動化,每次部署時都會發生錯誤。唯一的問題就是“該問題嚴重與否”而已。即使通過了良好的部署測試,有些錯誤也很難追查。

        • 如果部署過程不是自動化的,那么它就是不可重復的或不可靠的,就會在調試部署錯誤的過程中浪費很多時間。

        • 手動部署進程不得不記錄在案。文檔維護是一個復雜而費時的任務。它涉及多人之間的協作,因此該文檔基本上要么是不完整的,要么是未及時更新的。而把一個自動化部署腳本作為文檔,它就永遠是最新的和完整的,否則就無法進行部署工作了。

        • 自動部署本質上也是鼓勵協作的,因為所有的內容都在這個腳本里,一覽無遺。而文檔是建立在一種假設的基礎之上的,即讀者的知識水平與作者的水平相當??墒聦嵣?,這個文檔通常只是執行部署者所寫的備忘錄,他人并不清楚當時寫作的上下文。

        根據以上幾點,我們可以得到這樣的結論:手工部署過程需要部署專家。如果專家去度假或離職了,那你就有麻煩了。

        • 盡管手工部署是枯燥且重復性的勞動,但仍需要有相當程度的專業知識。一方面,專家要做這些無聊且重復性的工作,而另一方面,技術要求高的任務仍需要他們來完成。結果,我們只有通過“剝奪睡眠”這樣的方式來解決時間不足等問題啦。而自動化部署可以解放那些昂貴的高技能人員,讓他們投身于更高價值的工作活動當中。

        • 對手工部署過程本身進行測試的唯一方法就是原封不動地做一次(或者幾次)。這往往費時又昂貴。而自動化的部署過程卻是既便宜又容易測試。

        • 另外,還有一種說法:“自動化過程不如手工過程的可審計性好”。我們不同意這個觀點。對于一個手工過程來說,沒人能確保其執行者會非常嚴格地遵照文檔中所記述的內容。只有自動化過程是完全可審核的。有什么東西會比一個可工作的部署腳本更能夠被審核的呢?每個人都應該使用自動化部署過程,而且它應該是軟件部署的唯一方式。這個紀律可以確保:在需要部署時,部署腳本一定會很好地完成工作。在本書中我們會提到多個原則,而其中之一就是“使用相同的腳本將軟件部署到各種環境”。如果您使用相同的腳本將軟件部署到各類環境中,那么在發布當天需要向生產環境進行部署時,這個腳本已經被驗證過成百上千次了。如果此時出現任何問題的話,你可以百分百地確定是該環境的具體配置問題,而不是這個腳本的問題。

        當然,手工密集操作的發布工作有時也會非常順利。但不幸的是,我們經??吹降膮s是糟糕的情況。假如在整個軟件生產過程中它不算是一個易出錯的步驟,那為什么還總是出錯呢?為什么需要這些流程和文檔呢?為什么團隊在周末還要加班呢?為什么還要求大家原地待命,以防意外發生呢?

        第二類:只有在開發完成之后,才能向類生產環節上部署

        當軟件開發完成后第一次被部署到類生產環境(比如試運行環境)時,開發團隊認為“該軟件開發完成了”。

        這種模式中,經??吹较旅孢@些情況:

        • 測試人員部署之前就已參與開發流程,但只在開發環境中對軟件應用進行了測試。

        • 只有在向試運行環境部署時,運維人員才第一次接觸到這個應用程序。在某些組織中,通常是由獨立的運維團隊負責將應用程序部署到試運行環境和生產環境。在這種工作方式下,運維人員只有在產品發布到生產環境時才第一次見到這個軟件。

        • 有可能由于類生產環境非常昂貴,權限控制嚴格,操作人員自己無權對該環境進行操作,也有可能環境沒有按時準備好,甚至根本沒人去準備環境。

        • 開發團隊將正確的安裝程序、配置文件、數據庫遷移腳本和部署文檔一同交給那些真正執行部署任務的人員——而所有這些產物都沒有在生產環境或試運行環境中進行過測試。

        • 開發團隊和真正執行部署任務的人員之間的協作非常少。

        當需要將軟件部署到試運行環境時,只是臨時地組成一個團隊來完成這項任務。有時候這個團隊可能是一個全功能團隊,然而在一個大型組織中,這種部署責任通常落在多個分立的團隊肩上。DBA、中間件團隊、Web團隊,以及其他團隊都會染指應用程序最后版本的部署工作。因為部署工作中的很多步驟根本沒有在試運行環境上測試過,所以常常遇到問題。文檔中也漏掉了一些重要的步驟。這些文檔都基于一個基本假設,即軟件版本或目標環境的配置都是正確的。然則情況常常恰恰相反,而引起部署失敗。部署團隊不得不猜測開發團隊到底是怎么做的。

        這種因缺乏合作而導致部署問題的情況最終會通過臨時打電話、發郵件給開發人員,讓他們做一些快速修復來解決。一個嚴格自律的團隊會將所有可能性寫到部署計劃中,但卻很少真正讓這個過程變得更有效。隨著部署壓力的增大,為了能夠在規定的時間內完成部署,開發團隊與部署團隊之間這種嚴格定義的協作過程被證明是失敗的。

        有的時候,情況會比這還糟。 以下這些事情會使問題惡化。

        • 當一個應用程序是全新開發的,當第一次將它部署到試運行環境時,可能會比較棘手。

        • 發布周期越長,開發團隊在錯誤的假設下開發的時間就越長,修復這些問題的時間就越長。

        • 在那些劃分有開發、DBA、運維、測試等部門的大型組織中,這些獨立部門之間的協作成本可能會非常高,有時甚至會將發布過程拖上地獄列車。此時為了完成某個部署過程,開發人員、測試人員和運維人員之間總是是高舉著問題單(不斷地互發EMail)。更糟糕的是,這些Email都是為了解決部署過程中發現的問題。

        • 開發環境與生產環境差異性越大,開發過程中所做的那些假設與現實差距就越大。雖然很難度量,但我敢說,如果你在Windows系統上開發軟件,卻最終需要部署到Solaris集群上,那么你會遇到很多意想不到的事情。

        • 如果你的應用程序是由客戶自行安裝的(你可能沒有權限操作客戶的環境),或者其中的某些組件不在企業控制范圍之內。此時可能需要很多額外的測試工作。

        那么,

        良藥就是將測試、部署和發布活動也納入到開發過程中,讓它們成為正常開發流程的一部分。當需要進行系統發布時就不會有什么風險了,因為你已經在很多種環境,甚至類生產環境中已經做過很多次,相當于測試過很多次了。而且要確保每個人都成為這個軟件交付流程的一份子,無論是構建發布團隊、還是開發測試人員,都應該從項目開始就在一起工作。
        我們是測試的狂熱者,并將持續集成和持續部署的使用范圍擴大了,即不但要對應用程序進行測試,還要對部署過程進行測試,這正是我們所推薦的方法的基石。

        第三類:生產環境的手工配置管理

        這種反模式的特征是:

        • 多次部署到試運行環境都非常成功,但當部署到生產環境時就失敗。

        • 集群中各節點的行為有所不同。例如,與其它節點相比,某個節點所承擔的負載少一些,或者處理請求的時間花得多一些。

        • 運維團隊需要較長時間為每次發布來準備環境。

        • 系統無法回滾到之前部署的某個配置上,這些配置包括操作系統、應用服務器、關系數據庫、Web服務器或其它基礎設施。

        • 不知道從什么時候起,集群中的某些服務器所依賴的操作系統和第三方庫的版本就不同了,或者更新了錯誤的補丁。

        • 直接修改生產環境上的信息來改變配置。

        在這個時候,我們需要讓測試環境、試運行環境和生產環境的所有方面,尤其是系統中的第三方軟件配置,通過一個自動化的過程從版本控制系統中取出并應用到該環境中。

        一個完善的自動構建、部署、測試和發布系統威力不可小覷,它可以通過事前操作以成百倍的效率提升整個環境的部署速度。即使出錯,也可以在同樣短的時間內實現回滾功能。

        EasyOps平臺通過綁定應用與程序包的操作,使得平臺在發布應用時仍可以對程序包實現

        1)版本管理

        2)回滾

        3)編輯權限

        等功能點,極大提升應用發布的效率。

        而過程,大概我們給一個3分5秒的視頻,你就明白了。

        所有文章
        ×

        還剩一步!

        確認郵件已發至你的郵箱。?請點擊郵件中的確認鏈接,完成訂閱。

        好的

        美女一级牲交视频