本文介紹了wercker和它的基本用法，並用我GitHub上的magpie應用作為示例，講解如何給GitHub專案增加wercker構建流程，並將生成的映象自動上傳到Docker Hub上。

CI工具

開源專案的構建離不開CI工具，你可能經常會在很多GitHub的開源專案首頁上看到這樣的東西：

這些圖示都是CI工具提供的，可以直觀的看到當前的構建狀態，例如wercker中可以在Application-magpie-options中看到：

將文字框中的程式碼複製到你的專案的README檔案中，就可以在專案主頁上看到這樣的標誌了。

現在市面上有很多流行的CI/CD工具和DevOps工具有很多，這些工具提高了軟體開發的效率，增加了開發人員的幸福感。這些工具有：

適用於GitHub上的開源專案，可以直接使用GitHub賬戶登陸，對於公開專案可以直接使用：Travis-ci、CircleCI、Wercker。從目前GitHub上開源專案的使用情況來看，Travis-ci的使用率更高一些。

不僅包括CI/CD功能的DevOps平臺：JFrog、Spinnaker、Fabric8

Wercker簡介

Wercker是一家為現代雲服務提供容器化應用及微服務的快速開發、部署工具的初創企業，成立於2012年，總部位於荷蘭阿姆斯特丹。其以容器為中心的平臺可以對微服務和應用的開發進行自動化。開發者通過利用其命令列工具能夠生成容器到桌面，然後自動生成應用並部署到各種雲平臺上面。其支援的平臺包括Heroku、AWS以及Rackspace等。

Wercker於2016年獲得450萬美元A輪融資，此輪融資由Inkef Capital領投，Notion Capital跟投，融資所得將用於商業版產品的開發。此輪融資過後其總融資額為750萬美元。

Wercker於2017年4月被Oracle甲骨文於收購。

為什麼使用Wercker

所有的CI工具都可以在市面上獲取，但為何要建議使用Wercker呢？依據雲之道的準則評估了所有工具，發現Wercker正是我們需要的。

首先，無須在工作站中安裝Wecker，僅安裝一個命令列客戶端即可，構建過程全部在雲端進行。

其次，不用通過信用卡就可使用Wercker。當我們迫切希望簡化流程時，這是一件令人讚歎的事。付款承諾這一條件大大增加了開發者的壓力，這通常是不必要的。

最後，Wercker使用起來非常簡單。它非常容易配置，不需要經過高階培訓或擁有持續整合的博士學位，也不用制定專門的流程。

通過Wercker搭建CI環境只需經過三個基本步驟。

1．在Wercker網站中建立一個應用程式。

2．將wercker.yml新增到應用程式的程式碼庫中。

3．選擇打包和部署構建的位置。

如何使用

可以使用GitHub帳號直接登入Wercker，整個建立應用CI的流程一共3步。

一旦擁有了賬戶，那麼只需簡單地點選位於頂部的應用程式選單，然後選擇建立選項即可。如果系統提示是否要建立組織或應用程式，請選擇應用程式。Wercker組織允許多個Wercker使用者之間進行協作，而無須提供信用卡。下圖為設定新應用程式的嚮導頁面。

選擇了GitHub中的repo之後，第二步配置訪問許可權，最後一步Wercker會嘗試生成一個wercker.yml檔案（後面會討論）。不過至少對於Go應用程式來說，這個配置很少會滿足要求，所以我們總是需要建立自己的Wercker配置檔案。

安裝Wercker命令列程式

這一步是可選的，如果你希望在本地進行wercker構建的話才需要在本地安裝命令列程式。本地構建和雲端構建都依賴於Docker的使用。基本上，程式碼會被置於所選擇的docker映象中（在wercker.yml中定義），然後再選擇執行的內容和方法。

要在本地執行Wercker構建，需要使用Wercker CLI。有關如何安裝和測試CLI的內容，請檢視http://devcenter.wercker.com/docs/cli。Wercker更新文件的頻率要比本書更高，所以請在本書中做個標記，然後根據Wercker網站的文件安裝Wercker CLI。

如果已經正確安裝了CLI，應該可以查詢到CLI的版本，程式碼如下所示。

Version: 1.0.882
Compiled at: 2017-06-02 06:49:39 +0800 CST
Git commit: da8bc056ed99e27b4b7a1b608078ddaf025a9dc4
No new version available

本地構建只要在專案的根目錄下輸入wercker build命令即可，wercker會自動下載依賴的docker映象在本地執行所有構建流程。

建立Wercker配置檔案wercker.yml

Wercker配置檔案是一個YAML檔案，該檔案必須在GitHub repo的最頂層目錄，該檔案主要包含三個部分，對應可用的三個主要管道。

— Dev：定義了開發管道的步驟列表。與所有管道一樣，可以選定一個box用於構建，也可以全域性指定一個box應用於所有管道。box可以是Wercker內建的預製Docker映象之一，也可以是Docker Hub託管的任何Docker映象。

— Build：定義了在Wercker構建期間要執行的步驟和指令碼的列表。與許多其他服務（如Jenkins和TeamCity）不同，構建步驟位於程式碼庫的配置檔案中，而不是隱藏在服務配置裡。

— Deploy：在這裡可以定義構建的部署方式和位置。

Wercker中還有工作流的概念，通過使用分支、條件構建、多個部署目標和其他高階功能擴充套件了管道的功能，這些高階功能讀著可以自己在wercker的網站中探索。

示例

我們以我用Go語言開發的管理yarn on docker叢集的命令列工具magpie為例，講解如何使用wercker自動構建，併產生docker映象釋出到Docker Hub中。

下面是magpie這個專案中使用的wercker.yml檔案。

box: golang
build:
  steps:
    # Sets the go workspace and places you package
    # at the right place in the workspace tree
    - setup-go-workspace

    # Gets the dependencies
    - script:
        name: go get
        code: |
          go get github.com/rootsongjc/magpie
    # Build the project
    - script:
        name: go build
        code: |
          go build -o magpie main.go
    # Test the project
    - script:
        name: go test
        code: |
          go test ./...
    - script:
        name: copy files to wercker output 
        code: |
          cp -R ./ ${WERCKER_OUTPUT_DIR}
deploy: 
  steps:
    - internal/docker-push:
        username: $USERNAME
        password: $PASSWORD 
        cmd: /pipeline/source/magpie
        tag: latest
        repository: jimmysong/magpie

此檔案包含兩個管道：build和deploy。在開發流程中，我們使用Wercker和Docker建立一個乾淨的Docker映象，然後將它push到Docker Hub中。Wercker包含一個叫做Internal/docker-push的deploy plugin，可以將構建好的docker映象push到映象倉庫中，預設是Docker Hub，也可以配置成私有映象倉庫。

box鍵的值是golang。這意味著我們使用的是一個基礎的Docker映象，它已經安裝了Go環境。這一點至關重要，因為執行Wercker構建的基準Docker映象需要包含應用程式所需的構建工具。

這部分存在一些難以理解的概念。當使用Wercker進行構建時，其實並沒有使用本地工作站的資源（即使在技術層面上，構建也是在本地執行的），相反，使用的是Docker映象中的可用資源。因此，如果要使用Wercker編譯Go應用程式，需要首先執行包含Go的Docker映象。如果想要構建唯一的工件，無論它是在本地還是在Wercker的雲端執行，使用Docker映象都是完全合理的。

本次構建中執行的第一個指令碼是go get。這一步可以go get可能需要的、但不包含在基礎映象中的任何東西。無論為指令碼設定什麼名稱，構建輸出都會有所顯示，如下圖所示。

在build管道中，接下來的兩個指令碼執行的構建和測試流程，最後一個指令碼是將構建後的檔案拷貝到wercker的輸出目錄中，我們將使用該目錄構建docker映象。

我們注意到deploy中有兩個變數：$USERNAME、$PASSWORD，這是我們自定義的變數，當你不希望將隱私內容直接寫在程式碼中的時候，可以在wercker中自定義變數，變數可以只作用於單個pipeline，也可以是所有pipeline共享的。

可以將變數設定成Protected模式，這樣只有設定者本人才知道該變數的值是什麼，其他人即使有共享訪問許可權，也看不到該變數的值，但可以重新設定來覆蓋原值。

Deploy管道中配置的docker映象的repo、tag和cmd命令，其他容器配置都在程式碼頂層目錄的Dockerfile中定義。當整個構建流程完成後，就可以在docker映象倉庫中看到剛構建的映象jimmysong/magpie:latest了。

總結

當然以上只是一個很簡單的示例，還有很多可以優化的流程，比如我們在示例使用latest作為docker映象的tag，wercker本身提供了很多內建和構建時環境變數，我們可以在wercker.yml檔案裡獲取這些變數作為命令中的值。

當比於其他CI工具，wercker配置簡單，更易於使用，同時在wercker的registry中還可以看到很多別人構建的pipline可供參考，還有十分友好的workflows可用於編排構建流程和依賴。

參考