Photo Credit : freddie boy via Compfight cc

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

原理說明

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

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

配置範例

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

.Ruby}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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 套件庫。

結語

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