隨著微服務架構與容器虛擬化技術的發展，持續集成與持續交付的概念又重新回到了大家的視野，越來越多的公司開始使用持續集成的系統來解決頻繁發布帶來的質量問題；使用持續交付的工具來實現代碼在不同環境上的自動部署。

持續交付的概念和產生

傳統軟件的開發與交付的周期都很漫長，一款普通的企業軟件通常需要十幾個開發人員，幾個月的時間來完成，從需求的分析、系統的設計、編寫測試用例、系統開發、單元測試、組裝測試到交付調試。有條不紊的流程與規范像一輛綠皮火車下的枕木，穩定而可靠的保證整個系統緩慢的推進，每一次交付、升級，都需要提供基礎的硬件、軟件的環境、軟件的代碼、軟件的文檔與手冊。
還記得剛剛邁入軟件開發行業的時候，跟隨公司的服務團隊，駐場交付產品，每一個駐場工程師都按照之前預演過好多遍的流程，對照著系統的部署手冊，一步一步的組裝硬件，安裝軟件，稍有差池，就要按照對應的應急預案進行回滾。開始的時候覺得交付像一個神圣的儀式，將用智慧和汗水構建成的軟件交付給客戶使用，是一種非常榮耀和值得驕傲的事情；后來越來越多次的產品交付讓我深深的感覺每一次交付都像分娩一樣痛苦，捫心自問是否有簡單更舒暢的流程可以將軟件交付給客戶呢？

?

要想快速的交付，首先要明白軟件交付過程中遇到的核心問題是什么。總結成兩個詞“自動”與“可靠”。自動是一個很寬泛的詞匯，在軟件交付中代表著測試自動化、交付自動化、運維自動化等等，而可靠講的是每一次交付要保證是當前的交付是穩定的或可回滾到穩定版本的。為了解決“自動”與“可靠”的問題，敏捷開發鼻祖Martin Fowler提出了持續集成與持續交付的概念，它所描述的軟件開發，是從原始需求識別到最終產品部署到生產環境這個過程中，需求以小批量形式在團隊的各個角色間順暢流動，能夠以較短地周期完成需求的小粒度頻繁交付。頻繁的交付周期帶來了更迅速的對軟件的反饋，并且在這個過程中，需求分析、產品的用戶體驗和交互 設計、開發、測試、運維等角色密切協作，相比于傳統的瀑布式軟件團隊，更少浪費。通過這種小步快跑的方式，將小功能快速迭代、驗證、交付，通過自動化的工具，將測試、部署、運維自動化，減少需求在軟件生命周期中流動的時間。

持續交付工具鏈

但是前輩只給了我們先進的思想，并沒有給出默認的實現。不同的公司、不同的產品、不同的技術棧、不同的開發與部署形態決定了持續集成與持續交付注定是因人而異的，大家不斷摸索什么樣的方式是持續集成與持續交付的最佳實踐。歸根結底，持續集成與持續交付的難點在于如何屏蔽不同語言、不同框架、不同系統之間的持續集成與持續交付流程的差異性。曾經幻想過是否能有一種方式可以歸約軟件的交付，而這就是Martin Fowler留給我們的課后思考題-論如何實現持續集成與持續交付的流程標準化。
當你問十個哲學家什么是哲學的時候，你會得到十一種答案，因為每個人都有對哲學不同的理解，對于持續交付也一樣。個人選取了目前開源社區中最流行和優秀的開源軟件，經過改造后搭建了全開源端到端交付流水線，這應該也是目前各大互聯網公司使用最廣泛的方案。其中Jenkins作為業內優秀的的CI/CD工具，擔任整套了工具鏈的核心組織工作。

?

持續交付 VS Devops

Devops定義：

DevOps（Development和Operations的組合詞）是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。

DevOps的出現有其必然性。在軟件開發生命周期中，遇到了兩次瓶頸。第一次瓶頸是在需求階段和開發階段之間，針對不斷變化的需求，對軟件開發者提出了高要求，后來出現了敏捷方法論，強調適應需求、快速迭代、持續交付。第二個瓶頸是在開發階段和構建部署階段之間，大量完成的開發任務可能阻塞在部署階段，影響交付，于是有了DevOps。

Devops三大原則：

1、基礎設施即代碼（Infrastructure as Code）
DeveOps的基礎是將重復的事情使用自動化腳本或軟件來實現，例如Docker（容器化）、Jenkins（持續集成）、Puppet（基礎架構構建）、Vagrant（虛擬化平臺）等
2、持續交付（Continuous Delivery）
持續交付是在生產環境發布可靠的軟件并交付給用戶使用。而持續部署則不一定交付給用戶使用。涉及到2個時間，TTR（Time to Repair）修復時間，TTM（Time To Marketing）產品上線時間。要做到高效交付可靠的軟件，需要盡可能的減少這2個時間。部署可以有多種方式，比如藍綠部署、金絲雀部署等。
3、協同工作（Culture of Collaboration）
開發者和運維人員必須定期進行密切的合作。開發應該把運維角色理解成軟件的另一個用戶群體。協作有幾個的建議：1、自動化（減少不必要的協作）；2、小范圍（每次修改的內容不宜過多，減少發布的風險）；3、統一信息集散地（如wiki，讓雙方能夠共享信息）；4、標準化協作工具（比如jenkins）

持續交付和Devops的關系

devops（開發到運維）是另外一個現在很火的工程概念，和持續交付的關系很多時候讓人傻傻分不清楚。從概念上來說，DevOps更關注Ops(Operations), 持續交付更關注Dev (Development) 。他們的目標都是解決相同的問題，即加速軟件開發，減少軟件開發到交付或上線的時間，并使開發、測試、運維幾個角色協作的更緊密。一般來說個人傾向于兩者說的是同一回事，它們只不過是一枚硬幣的正反面而已，在概念上并沒有什么爭議。
引用《持續交付》譯者喬梁的觀點，細微的差別可能就是持續交付體現的是產品交付的完整過程，devops強調的是從開發到運維的交付，傳統的持續集成則更強調產品研發過程（開發+測試）。

?

持續交付產品：

博客將會對這些產品一一介紹

• jenkins
• docker
• maven
• git
• jmeter?
• zabbix
• elk
• sonar

?

總結

以上是生活随笔為你收集整理的持续交付的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。