01 Jenkins pipeline parallel(jenkins之pipeline相關概念)

jenkins之pipeline相關概念

pipeline是什么，有什么作用，用groovy語言編寫

創建pipeline操作步驟：

1、安裝jenkins 和安裝插件 pipeline。

2、新建一個pipeline項目，在pipeline中加入腳本，構建執行。

部署流水線：Deployment pipeline,從軟件版本控制庫到用戶手中這一過程的自動化表現形式。

所有的部署流水線都寫在jenkins-file文件中，需要安裝插件pipeline插件后才能使用jenkins-file。

1.pipeline最簡單的結構

pipeline是什么，用于描述整條流水線是如何進行的。流水線的內容包括執行編譯、打包、測試、輸出測試報告等步驟。以下5個部分是pipeline的必需存在的，少一個，jenkins都會報錯。

2.pipeline的步驟

pipeline基本結構決定的是pipeline整體流程。

pipeline plugin的github倉庫： 買粉絲s://github.買粉絲/jenkinsci/pipeline-plugin/blob/master/README.md

jenkins pipeline支持的指令有：

聲明式（Delar-ative）語法&腳本式（Scripted）語法如圖：

Jenkins-pipeline中SSH方式登錄遠程機器

     pipeline{

   agent any

   stages {

       stage ('Pipeline 買粉絲nfiguration') {

                agent none

                steps {

                      script {

                        stage ('Pull & PushImage') {

                          def remote = [:]

                          remote.name = 'test'

                          remote.host ='192.168.248.190'

                          remote.user = 'root'

                          remote.password ='password'

                          remote.allowAnyHosts= true

                          writeFile file:'jemeter.sh', text: 'cd /ibm \n ls'

                          sshScript remote: remote,script: "jemeter.sh"

                            }

                       }

                  }   

           }

      }

}

如何用Jenkins/Hudson創建真正的pipeline

如何用Jenkins/Hudson創建真正的pipeline

這幾天嘗試用Jenkins/Hudson創建pipeline，發現網上的信息很少，所以寫一篇跟大家分享。

在開始之前，得告訴你被我的標題給忽悠了，不是Jenkins/Hudson，只是Jenkins！如果你還在用Hudson，那么我建議你立即切換到Jenkins。理由就不說了，看看這個投票就行。（此中，我吃盡了苦頭）

接下來，就讓我們一步一步用Jenkins搭建真正的pipeline吧。

第一步

第一步，我們先創建一個最簡單的pipeline。所謂pipeline，顧名思義，就是一個流水線，由多個步驟（steps）組成。每走完一步，就來到下一步。用Build Pipeline Plugin就可以很方便地實現。

實現的效果如下圖：

上例中，UnitTest是我們的初始任務。UnitTest結束之后，自動觸發AC Test。如果通過了AC Test，團隊可以有選擇地部署到任意測試環境。

在配置這個插件時，最重要的就是選擇Initial Job。

然后，在每一個step（job）中選擇downstream step。可以是自動觸發（Build Other Projects），也可以選擇手動觸發（Manually Execute Downstream Project）。

第二步

第一步中我們實現了一個流水線，但這個只是看上去的流水線而已。在工廠的流水線中，歷經流水線上游到下游的，應該是同一個產品。但上例中顯然不是，Unit Test和Acceptance Test所運行的可能是不同版本的代碼。

要讓幾個step的代碼運行在同一個版本，可以使用一個叫做Parameterized Trigger Plugin。如下圖：

選擇把Subversion revision傳到下面的steps，則接下來的Steps都會checkout同一個版本的代碼。但這個也有限制，就是這些Steps必須有相同的subversion URL配置。

另外，你應該還注意到我們還傳了另一個參數：PL_BUILD_NUMBER。這個參數會另有用途。

除了希望保持相同版本，我們很可能希望重用upstream step生成的artifact。比如，在AC Test step會生成一些artifacts，這些artifacts經過測試之后，希望可以用于Deploy步驟。一方面，這會節省重新構建artifact的時間；另一方面，這些artifact是已經經過測試的，是可用的，而重新構建生成的卻是未經測試的，可用與否未知。（雖然他們應該是一樣的，但誰知道呢。。）我們可以使用ArtifactDepolyerPlugin實現。