如何理解持續集成、持續交付、持續部署

項目開發可以分爲這幾個過程
編碼 -> 構建 -> 集成 -> 測試 -> 交付 -> 部署

首先引用一個例子

譬如說,你開了一家公司,僱了很多碼農在一起寫代碼。

  • 你說,要用 Gitlab 做代碼管理。當一個碼農在自己的開發機上寫好代碼之後,要合併到主分支裏,他首先要發起一個 Merge Request(MR),這會在一個特定服務器上觸發一次對他提交的代碼的檢查,包括代碼格式檢查、依賴關係檢查以及單元測試等一系列檢查,等通過了全部檢查,他就可以將代碼合併到主分支,否則他需要按照錯誤提示進行修改,然後發起新一輪的檢查。然後呢,每天晚上 10 點會有一個定時任務從主分支上拿最新的代碼,進行編譯打包,最後將打包好的程序推送到一個服務器上保存,這個服務器叫做 Artifact Repository,也就是Jenkins。
  • 你又說,要每天將當天打包好的程序部署到測試環境上。也就是說,一個碼農晚上 10 點之前提交了代碼,那他第二天就可以在測試環境上看到自己新提交的代碼的效果了。
  • 你 還說,每一個月要在生產環境上部署一個穩定的發佈版本。

這三個事例可以分別對應持續集成、持續交付以及持續部署。

1、持續集成(Continuous Integration)

在傳統軟件開發過程中,集成通常發生在每個人都完成了各自的工作之後。在項目尾聲階段,
通常集成還要痛苦的花費數週或者數月的時間來完成。持續集成是一個將集成提前至開發週期的早期階段的實踐方式,
讓構建、測試和集成代碼更經常反覆地發生。

持續集成就是把多個碼農寫的代碼集成到同一個分支,
然後經過編譯、測試、打包之後將程序保存到 jenkins裏。
在這裏插入圖片描述

2、持續交付(Continuous Delivery)

持續交付就是定時地、自動地從 Artifact Repository 將最新的程序部署到測試環境裏。
在這裏插入圖片描述

3、持續部署(Continuous Deployment)

持續部署就是定時地、自動地將過去一個穩定的發佈版本部署到生產環境裏。
在這裏插入圖片描述
很明顯,集成、交付和部署是軟件開發到發佈流程中的不同階段。那所謂的持續是相對於過去的流程提出的。過去的流程是所有人寫好代碼之後再進行合併,然後再進行測試,最後再發布。這種流程會把風險堆到軟件發佈前的最後階段。那持續的概念就是,做一點就馬上遞交給下一個流程,這樣能夠儘早地發現並解決問題。

4.補充說明

所謂的持續,就是說每完成一個完整的部分,就向下個環節交付,
發現問題可以馬上調整。使得問題不會放大到其他部分和後面的環節。
隨着DevOps不斷受到重視,頻繁部署、快速交付以及開發測試流程自動化都將成爲未來軟件開發的重要組成部分。

文章引用

如何理解持續集成,持續交付,持續部署

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章