前言

有了建構持續整合系統後 , 那要如何管理軟體建構工作 (build jobs)? 大部份的人可能都習慣使用 Jenkins 提供的使用者界面 , 但既然我們透過 Puppet 來管理 Jenkins 系統 , 沒道理不能用它來管理建構工作 。 本文山姆鍋以使用 Puppet 配置 Jenkins 工作來總結 “ 建構自己的雲端持續整合系統 ” 這一系列文章 。

原理說明

Jenkins 安裝在 /var/lib/jenkins 這個目錄 , 相關的建構工作放在 /var/lib/jenkins/jobs/${job_name}。 每個工作都在自己的子目錄 , 跟該工作相關的資料也都存在該目錄中 。 因為這樣的設計 , 其實管理 Jenkins 的建構工作 , 說穿了 , 就是建立相關的目錄以及設定檔 。

山姆鍋提供的 Jenkins 這個模組 , 其中定義了 jenkins::job 這種資源讓您可以使用 Puppet 來定義工作 , 這個資源定義是由 pgr0ss 提供 。 所有的工作定義都是由這個資源來提供 , 也就是說 : 如果您在 Puppet 的配置檔中刪除其中一個工作定義 , 對應的 Jenkins 工作也會被刪除 。 同樣的 , 當工作定義有變動時 ,Jenkins 服務也會被重新啟動以讓變動生效 。

配置範例

底下是原作者提供的兩個工作定義範例 :

jenkins::job { "app1_master":
    git_repo => "https://github.com/user/app1",
    git_branch => "master",
    command => "./ci.sh",
    triggers => ["app1_master_integration"]
}

jenkins::job { "app1_master_integration":
    git_repo => "https://github.com/user/app1",
    git_branch => "master",
    command => "./ci.sh integration",
    poll => false,
    build_schedule => "H H * * *"
}

限制

雖說是限制 , 其實是故意這樣設計 。 由於假設 Jenkins 持續整合系統是隨時可以建構或銷毀 , 因此 , 設計上就不假設會有長久性的資料放置在上面 。 也就是說 , 對於後續要用到的資料或檔案要放到別的服務器 。 例如 : 將產生的安裝套件上載到 Maven 套件庫 。

結語

這個方案在寫這篇文章的時候 , 山姆鍋還沒有開始實際使用 , 後續會再根據實際使用狀況來調整 。