最基本的持續交付管道至少有三個階段,應該在Jenkinsfile
中定義:Build
、Test
和Deploy
,對於本節,咱們將主要關注部署階段,但應注意穩定的構建和測試階段是任何部署活動的重要前提。node
Jenkinsfile (Declarative Pipeline) pipeline { agent any stages { stage('Build') { steps { echo 'Building' } } stage('Test') { steps { echo 'Testing' } } stage('Deploy') { steps { echo 'Deploying' } } } }
腳本管道(高級):segmentfault
Jenkinsfile (Scripted Pipeline) node { stage('Build') { echo 'Building' } stage('Test') { echo 'Testing' } stage('Deploy') { echo 'Deploying' } }
一種常見模式是擴展階階段的數量以捕獲額外的部署環境,如「staging」或「production」,以下面的代碼段所示。測試
stage('Deploy - Staging') { steps { sh './deploy staging' sh './run-smoke-tests' } } stage('Deploy - Production') { steps { sh './deploy production' } }
在這個例子中,咱們假設咱們的./run-smoke-tests
腳本運行的任何「煙霧測試」都足以對產品環境的發佈進行限定或驗證,這種自動將代碼一直部署到生產的管道能夠被視爲「持續部署」的實現。雖然這是一個崇高的理想,但對於許多人而言,有充分理由說明爲何持續部署可能不切實際,但仍然能夠享受持續交付帶來的好處,Jenkins管道很容易同時支持這兩種方法。ui
一般在階段之間傳遞,特別是環境階段,你可能須要在繼續以前人工輸入,例如,判斷應用程序是否處於足夠好的狀態以「促進」生產環境,這能夠經過input
步驟完成。在下面的示例中,「Sanity check」階段實際上阻塞了輸入,而且在沒有人確認進度的狀況下不會進行。code
Jenkinsfile (Declarative Pipeline) pipeline { agent any stages { /* "Build" and "Test" stages omitted */ stage('Deploy - Staging') { steps { sh './deploy staging' sh './run-smoke-tests' } } stage('Sanity check') { steps { input "Does the staging environment look ok?" } } stage('Deploy - Production') { steps { sh './deploy production' } } } }
腳本管道(高級):教程
Jenkinsfile (Scripted Pipeline) node { /* "Build" and "Test" stages omitted */ stage('Deploy - Staging') { sh './deploy staging' sh './run-smoke-tests' } stage('Sanity check') { input "Does the staging environment look ok?" } stage('Deploy - Production') { sh './deploy production' } }
本指南向你介紹了使用Jenkins和Jenkins管道的基礎知識,因爲Jenkins具備極高的可擴展性,所以能夠對其進行修改和配置,以處理幾乎任何自動化方面,要了解有關Jenkins能夠執行的操做的更多信息,請查看用戶手冊或Jenkins博客,瞭解最新的事件、教程和更新。事件