1、傳統(tǒng)我們的項目開發(fā)模式是產(chǎn)品調(diào)研提出需求，開發(fā)團隊研究決定開發(fā)方案選型。然后開始一個周期的開發(fā)，模塊開發(fā)完成之后開始模塊間的聯(lián)調(diào)。聯(lián)調(diào)結(jié)束之后打包交付給測試團隊。測試團隊，系統(tǒng)測試或自動化測試，然后提交bug，開發(fā)團隊修復(fù)bug，周而復(fù)始。

2、傳統(tǒng)的模式中，存在著較多的不確定因素。例如，開發(fā)環(huán)境、編譯環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境，等不確定因素。人為介入打包中的不確定因素，缺乏單元測試和自動化測試的整合。從而導(dǎo)致的結(jié)果是，開發(fā)-測試-修復(fù)的周期較長，而且很多小的問題完全可以由單元測試進行覆蓋。

持續(xù)交付并不是某個特定的軟件，而是一個結(jié)果。這個結(jié)果要求團隊可以隨時的發(fā)布一個新的準確版本，而且要求在編譯發(fā)布的過程中進行自動化測試，通過自動化測試可以及時的發(fā)現(xiàn)并定位存在的bug，修復(fù)bug之后再進行快速的發(fā)布到測試環(huán)境，測試團隊直接進行測試。

與傳統(tǒng)模式的區(qū)別在于持續(xù)交付可以提前發(fā)現(xiàn)bug的存在和快速修復(fù)而不必等到測試人員的介入之后才發(fā)現(xiàn)。持續(xù)交付分解出來就是“持續(xù)”和“交付”。 持續(xù) :持續(xù)要求任何時，候任何情況都能進行準確的發(fā)布，做到準確的發(fā)布需要注意以下幾個關(guān)鍵點。

持續(xù)應(yīng)該是一個周期性的，可以是每天的某個時間點，也可以是某次代碼的提交，或者某次人為觸發(fā)。所以人工進行構(gòu)建是不可能的，需要自動化的構(gòu)建，自動化要求構(gòu)建的任何一個流程都必須以腳本的形式運行，代碼檢出、代碼構(gòu)建、各模塊代碼單元測試、集成測試、UI自動化測試等。

發(fā)布的程序版本不允許是各個模塊在開發(fā)環(huán)境編譯出一個版本作為交付，而要求在一個純凈的編譯環(huán)境中進行構(gòu)建。

構(gòu)建的過程應(yīng)該要求最大可能的固化，例如操作系統(tǒng)的版本，構(gòu)建環(huán)境的版本，相關(guān)的依賴等。

避免從網(wǎng)絡(luò)獲取相關(guān)的文件，這點以nodejs為開發(fā)或編譯的項目尤其重要，安裝node的依賴包總是一個漫長的過程，就算有國內(nèi)的源，一般的項目也需要一兩分鐘的node依賴包，這不符合快速構(gòu)建。

交付 : 在持續(xù)編譯的過程，使用自動化已經(jīng)可以避免大多數(shù)的錯誤了。但是還是需要人為介入的系統(tǒng)測試，畢竟自動化的測試一般只能覆蓋到70%左右。

根據(jù)我們團隊內(nèi)部推廣這種工作方式的效果來看，持續(xù)集成確實讓我們工作便利了許多， 每次代碼的構(gòu)建和自動化測試讓我們及時發(fā)現(xiàn)存在的bug。好的工作模式也需要團隊成員的遵守，團隊成員應(yīng)該積極的擁抱這種工作方式，團隊成員需要做好以下幾點。

使用版本工具例如git。git有強大的版本回溯，成員每次完成一個小的功能點進行代碼提交。合并到master分支，持續(xù)交付工具應(yīng)該配置為代碼更新觸發(fā)。團隊內(nèi)部應(yīng)該等到持續(xù)交付流程結(jié)束之后，確認編譯、自動化測試通過之后方可進行下一個版本的提交，這樣容易定位bug。而不會導(dǎo)致這次bug影響團隊內(nèi)其他成員的工作。

主分支的代碼bug不應(yīng)該存留時間過長，避免團隊內(nèi)其他成員合并代碼的時候引入其他問題。

測試驅(qū)動開發(fā)，任何一個新的功能開發(fā)都應(yīng)該先寫好單元測試腳本，并積極更新自動化測試腳本。并且積極地擁抱測試，雖然你明白這個測試不通過的問題并不會引起很大的系統(tǒng)性問題 ，但是還是應(yīng)該進行修復(fù)而不是想方設(shè)法的跳過這個自動化測試。

臨近下班的時候不要提交代碼，這主要是因為遵守第2點。

Docker已經(jīng)越來越火，CICD和Devops也是Docker一個重要的場景。在持續(xù)交付中使用Docker有一下優(yōu)點。

Docker強大的環(huán)境隔離性可以將環(huán)境和程序打包在一起，測試、運維，人員無需知道我們的程序是如何配置的，只需要一條docker 的命令就可以將我們的程序運行起來，這也更加容易實現(xiàn)持續(xù)部署。

減少編譯環(huán)境的污染，因為Docker天然的隔離性，也避免了傳統(tǒng)編譯環(huán)境難以配置多套編譯環(huán)境的問題。在基于Docker的持續(xù)發(fā)布中，我們可以在同一臺宿主機上同時編譯不同版本的Java項目，不同版本的Python項目，而無需任何配置，鏡像也只是從docker hub中獲取。

持續(xù)集成

在持續(xù)集成方面，我們選擇Jenkins。Jenkins是一款開源軟件，擁有眾多優(yōu)秀的插件，依靠這些插件，我們可以完成一些周期、繁瑣、復(fù)雜的任務(wù)。例如我們今天分享的持續(xù)發(fā)布，雖然Jenkins解決了我們繁瑣復(fù)雜周期性的操作，但是沒有解決我們在多種環(huán)境下編譯構(gòu)建的需求。而這個場景正是Docker的強項。

通過Jenkins的pipeline我們可以實現(xiàn)代碼檢出、單元測試、編譯、構(gòu)建、發(fā)布、測試等流程的自動化，而最終通過Jenkins的Docker插件將產(chǎn)出物構(gòu)建成鏡像，方便部署到Docker環(huán)境。

持續(xù)部署

持續(xù)集成讓我們新的代碼源源不斷的構(gòu)建成了鏡像，這些鏡像經(jīng)歷了單元測試，自動化測試，但還沒有接受過測試團隊的嚴格測試。Jenkins是一個強大的持續(xù)集成工具，然而持續(xù)部署并不是Jenkins的強項，但是Jenkins擁有很多強大的插件。22.而且我們持續(xù)集成產(chǎn)出的是鏡像，所以持續(xù)的部署，我們只需要將鏡像運行起來，或者利用第三方的容器管理平臺提供的API進行部署。

本地部署應(yīng)用到Docker:本地部署到Docker容器可以使用Jenkins的docker插件，下面會介紹。

部署到遠程主機的Docker、Appsoar。Docker和Appsoar都支持開啟API調(diào)用。通過現(xiàn)有的API我們可以運行我們生成鏡像版本。從而達到持續(xù)的部署最新版本。

部署到kubernetes。kubernetes除了可以通過API調(diào)用還可以在jenkins中配置kubectl的方式創(chuàng)建或更新deployments。

Docker中運行Jenkins: Docker部署Jenkins的方式簡單方便，下面我們介紹用Docker的方式運行Jenkins。

這里將docker.sock和docker的可執(zhí)行文件掛載到j(luò)enkins容器中，這樣我們就可以在容器中使用docker了。

jenkins容器，默認的用戶是jenkins因為我們需要使用docker所以我們需要使用root用戶。

/var/jenkins_home的掛在卷是可選的，jenkins_home存放了所有任務(wù)、日志、認證、插件等jenkins運行后的文件。可做數(shù)據(jù)恢復(fù)使用。

配置Jenkins

解鎖jenkins:解鎖的密碼在容器的log中可以查看，或者直接查看jenkins_home指定文件

選擇插件

創(chuàng)建Pipeline

下面我們創(chuàng)建一個的Jenkins的Pipeline完成簡單的cicd流程。

新建pipeline，在左側(cè)新建選擇pipeline。

在左側(cè)的Credentials中新建git和鏡像倉庫的credentials

配置pipeline，例如定時觸發(fā)，代碼更新觸發(fā)，webhook觸發(fā)等。

在pipeline script中填入下面的demo.

以下是偽代碼，僅提供思路

Jenkins pipeline的腳本語法是groovy的語法，其中docker 、Git是插件提供的能力。代碼的執(zhí)行流程如下：

通過Git插件獲取最新代碼到j(luò)enkins的工作區(qū),例如`/var/jenkins_home/workspace/pipelineDemo。

docker.image().inside是如何編譯我們的代碼呢，通過查看Jenkins的console 可以看到如下log.

通過docker插件提供的能力構(gòu)建鏡像，Dockerfile存放在代碼目錄中。構(gòu)建鏡像后push到鏡像倉庫，私有倉庫需要自行配置鏡像倉庫。

鏡像構(gòu)建完成之后就可以刪掉舊版本，并重新運行一個新的版本。

熟悉Docker命令的朋友應(yīng)該很容易理解了，原來是docker.image().inside啟動的時候會將當前的目錄掛在到容器中，然后在容器中執(zhí)行./script/build.sh，這樣我們就完成了利用容器中存在的環(huán)境做單元測試或構(gòu)建編譯了。

通過簡單的例子，可見Jenkins和Docker的結(jié)合給CICD帶來了足夠的便利和強大。我們需要準備的只是一個編譯的腳本，在編譯腳本中可以使用任何的環(huán)境和任何的版本。

Pipeline 介紹

Jenkins 的任務(wù)兩個主要版本。

free style 只是一個自動化的腳本，腳本類型為shell。所有的腳本在一臺機器上運行，需要的環(huán)境需要提前準備。配置不集中，混亂。但是一般情況下還是夠用的。

pipeline 是jenkins2的版本使用了一個基于groovy腳本的任務(wù)類型，通過一系列的stage 將構(gòu)建的不同部分組合成一個pipline。而且配合step可以完成異步操作。因為基于groovy可編程性更加

強大，而且腳本可以存放在源碼中，腳本的更改不需要直接到j(luò)enkins中修改。

pipeline的一些使用經(jīng)驗和技巧

jenkins的資料較少，官網(wǎng)可以查看的內(nèi)容也不多，一般的需求Jenkins內(nèi)置的pipeline-syntax里面就有常用的命令生成器�？梢詽M足大多數(shù)需求。

在pipeline腳本調(diào)試完成之后應(yīng)該將腳本以文件的形式放在源碼目錄中，這樣子方便修改。和多分支需要編譯的情況下進行互相隔離。

應(yīng)該多查找下相應(yīng)的插件，而不是使用sh用執(zhí)行腳本的方式來解決問題。

應(yīng)該將jenkins_home目錄掛在出來，如果遇上了Jenkins崩潰了可以及時的恢復(fù)數(shù)據(jù)。

應(yīng)該新建一個定時的pipeline用來清理生成的鏡像，減少硬盤資源的占用。

頁面新建的pipeline,在頁面刪除之后，jenkins_home/workspace中對應(yīng)的項目文件并不會被刪除。

標簽： 操作系統(tǒng)  �源软�

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。