03 jenkins搭建測試環境(接口自動化測試環境搭建jmeter+ant+git+jenkins)

ed to GitLab. GitLab CI Service URL: …

添加hook

由于我們的jenkins任務由webhook事件來通知，所以需要將上面的CIservice URL添加到gitlab對應項目的Integrations配置中。

RUN

配置完之后apply，保存。jenkins任務就新建完成了此時我們在本地push代碼到gitlab服務器，可以看到：成功地觸發一次jenkins構建，效果如下：

至此jenkins+gitlab持續集成環境搭建完成！

如何用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實現。

很赞哦!（4）