Java應用持續交付系列一:持續交付基礎

我們最重要的目標,是通過持續不斷地及早交付有價值的軟體使客戶滿意。——敏捷宣言遵循的首要原則

談了這麼多天的Java基礎知識,其實講來講去也都是老生常談,我們今天聊點有意思的東西——CICD。目前國內的CICD這一塊的成熟的產品還不是很多。但是這個話題(DevOps中的重頭戲)還挺多人參與討論的。今天我們就講一下其中的CD:持續交付,並且後面會把如何將Java應用程序使用CD的技術方案來實現。

持續交付(CD)從根本上說是一套基於軟體交付團隊在短周期內生產功能完善的、有價值的軟體的實踐過程和解決方案。

持續交付過程中要確保功能是以小規模完整功能點的增量開發的模式進行開發的,軟體在任何一個時間段都可以發布出一個可靠的版本。並且可以在最快的時間獲取反饋和進行下一版本的改進和新技術的接納。

Advertisements

使用Java Build Pipeline進行持續交付

一個使用Java Build Pipeline進行持續交付的正常流程通常是:代碼從開發者們的電腦中提交到版本控制服務(git)中。然後開始整個pipeline的流程。一般來說會經過CI的構建(此時會有sonar的質量檢測),構建通過的程序會自動分發到QA進行功能測試(此時可用Cucumber或者JMeter同是進行性能測試和介面測試)。QA通過之後一般會部署到一個Stable環境中進行冒煙測試,且此時的版本已經是待發布的版本。只要是確認要上線的立刻把stable環境下的程序部署到線上。

使用Pipeline構建的主要目的是保證任何新增或者修改後的功能都是可以到准產品的級別。只要是有任何一個環節不符合CICD的標準的都不會完成整個pipeline。

Advertisements

從最初的代碼的改變到應用程序的構建和測試都是獨立分開的,我們也可以並且應該使用像SonarQube這樣的工具來對應用進行分析。代碼成功通過了上面的步驟和功能測試和代碼質量指標測試後會走到stable環境中,並在更大的綜合背景下進行聯調測試。完美驗證后的代碼就會從pileline中產生並被標記為準備部署到生產中。 當連續使用這樣的邏輯來進行代碼生產的時候我們稱之為連續交付。

力求最大限度地反饋:所有的事情都可以自動化

build pileline必須為開發團隊提供快速的反饋,以便在日常工作中高效的時候。 在這一流程中有許多項目都是可以百分百用自動化的機器來完成的,並且是在高效的無錯誤的情況下進行的。我們可用工具來提高我們的生產效率。 以下項目應該是自動的:

  • 軟體編譯和代碼質量靜態分析

  • 功能測試:包括單元測試、集成測試和e2e

  • 生成所有的測試環境

  • 日誌記錄

  • 監控和alarm hook

  • 將軟體部署到所有環境中

  • 存儲數據的遷移

  • 系統測試,包括故障模擬等等非功能性要求

  • 性能和安全性

  • 跟蹤和審核更改歷史

使用Container來進行CD

上面描述的就是一個基於Java的pipeline的流程,不論你是java項目還是Spring項目都可以使用。通常我們都是打包成一個jar包或者一個war包的模式來進行部署。然後將通過CD的最終產品包存放在repository中例如:Nexus等。這些流程都可以用Docker來做一個包裝。

如果直接把一個jar包或者一個war包類比成一個Docker鏡像的話是不準確的。事實上,你可以認為這是用一個發動機來類比了一輛汽車的概念。基於這個概念。對於Docker不熟悉的Java開發人員可能對於發動機更加熟悉。我們的內容是基於Java開展的。不過多討論Docker的機制。如果大家對於Docker有興趣的話可以閱讀其他的相關書籍。目前種類還是蠻多的。

Docker鏡像其實就是一個在Linux中作為一個容器運行的操作系統,目前有很多種OS的docker鏡像,從輕量級的Alpine Linux、Debian Jessie,到像Ubuntu,CentOS或者、全功能的RHEL。 不管操作系統如何選擇,所以基於Java的Docker鏡像就是一個基於某一個已選定的os為基底的包含已安裝了所有運行時環境的java運行時操作系統。

Java應用程序包含在一個完整的操作系統給我們帶來了更大的靈活度,例如,允許安裝用於調試和診斷的OS實用程序。然而,權力越大,責任重大(風險增加)。在構建工件中封裝操作系統會增加開發人員的工作量。

引入Docker技術堆棧也意味著需要額外的開銷。

CD的核心原則之一是在類似生產環境中進行測試,儘快實施,容器技術可以做到這一點與更傳統的部署方式相比更容易。在生產環境中,如Docker Swarm,Kubernetes(nanokube)和Mesos(minimesos)通常可以直接在開發人員的筆記本電腦或雲實例上直接運行。

但是構建Java應用程序的複雜性增加由於引入看Docker之後有一定的增加。這個是不可避免的。然而為了出現更加可靠的部署環境。個人覺得這個開銷是可以接受的。今天只是概念性的描述。明天我們會系統性的描述Docker in Java的步驟。讓Docker IN Java不在是一個神乎其神的東西。

Advertisements

你可能會喜歡