snapcraft 是一個正在為其在 linux 中的地位而奮鬥的包管理系統，它為你重新設想了分發軟體的方式。這套新的跨發行版的工具可以用來幫助你建構和釋出 snap 軟體包。接下來我們将會講述怎麼使用 circleci 2.0 來加速這個過程以及一些在這個過程中的可能遇到的問題。
snap 軟體包是什麼?snapcraft 又是什麼?
snap 是用于 linux 發行版的軟體包，它們在設計的時候吸取了像 android 這樣的移動平台和物聯網裝置上分發軟體的經驗教訓。snapcraft 這個名字涵蓋了 snap 和用來建構它們的指令行工具、這個 snapcraft.io 網站，以及在這些技術的支撐下建構的幾乎整個生态系統。
snap 軟體包被設計成用來隔離并封裝整個應用程式。這些概念使得 snapcraft 提高軟體安全性、穩定性和可移植性的目标得以實作，其中可移植性允許單個 snap 軟體包不僅可以在 ubuntu 的多個版本中安裝，而且也可以在 debian、fedora 和 arch 等發行版中安裝。snapcraft 網站對其的描述如下：
為每個 linux 桌面、伺服器、雲端或裝置打包任何應用程式，并且直接傳遞更新。
在 circleci 2.0 上建構 snap 軟體包
在 circleci 上使用 circleci 2.0 文法 來建構 snap 和在本地機器上基本相同。在本文中，我們将會講解一個示例配置檔案。如果您對 circleci 還不熟悉，或者想了解更多有關 2.0 的入門知識，您可以從 這裡 開始。
基礎配置
version: 2
jobs:
build:
machine: true
working_directory: ~/project
steps:
- checkout
- run:
command: |
sudo apt update && sudo apt install -y snapd
sudo snap install snapcraft --edge --classic
/snap/bin/snapcraft
這個例子使用了 machine 執行器來安裝用于管理運作 snap 的可執行程式 snapd 和制作 snap 的 snapcraft 工具。
由于建構過程需要使用比較新的核心，是以我們使用了 machine 執行器而沒有用 docker 執行器。在這裡，linux v4.4 已經足夠滿足我們的需求了。
使用者空間的依賴關系
上面的例子使用了 machine 執行器，它實際上是一個核心為 linux v4.4 的 ubuntu 14.04 (trusty) 虛拟機。如果 trusty 倉庫可以滿足你的 project/snap 建構依賴，那就沒問題。如果你的建構依賴需要其他版本，比如 ubuntu 16.04 (xenial)，我們仍然可以在 machine 執行器中使用 docker 來建構我們的 snap 軟體包 。
docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c "apt update -qq && apt install snapcraft -y && cd $(pwd) && snapcraft"
這個例子中，我們再次在 machine 執行器的虛拟機中安裝了 snapd，但是我們決定将 snapcraft 安裝在 ubuntu xenial 鏡像建構的 docker 容器中，并使用它來建構我們的 snap。這樣，在 snapcraft 運作的過程中就可以使用在 ubuntu 16.04 中可用的所有 apt 包。
測試
在我們的部落格、文檔以及網際網路上已經有很多講述如何對軟體代碼進行單元測試的内容。搜尋你的語言或者架構和單元測試或者 ci 可以找到大量相關的資訊。在 circleci 上建構 snap 軟體包，我們最終會得到一個 .snap 的檔案，這意味着除了創造它的代碼外我們還可以對它進行測試。
工作流
假設我們建構的 snap 軟體包是一個 webapp，我們可以通過測試套件來確定建構的 snap 可以正确的安裝和運作，我們也可以試着安裝它或者使用 selenium 來測試頁面加載、登入等功能正常工作。但是這裡有一個問題，由于 snap 是被設計成可以在多個 linux 發行版上運作，這就需要我們的測試套件可以在 ubuntu 16.04、fedora 25 和 debian 9 等發行版中可以正常運作。這個問題我們可以通過 circleci 2.0 的工作流來有效地解決。
工作流是在最近的 circleci 2.0 測試版中加入的，它允許我們通過特定的邏輯流程來運作離散的任務。這樣，使用單個任務建構完 snap 後，我們就可以開始并行的運作 snap 的發行版測試任務，每個任務對應一個不同的發行版的 docker 鏡像 (或者在将來，還會有其他可用的執行器)。
這裡有一個簡單的例子：
workflows:
version: 2
build-test-and-deploy:
jobs:
- build
- acceptance_test_xenial:
requires:
- build
- acceptance_test_fedora_25:
- acceptance_test_arch:
- publish:
- acceptance_test_xenial
- acceptance_test_fedora_25
- acceptance_test_arch
在這個例子中首先建構了 snap，然後在四個不同的發行版上運作驗收測試。如果所有的發行版都通過測試了，那麼我們就可以運作釋出 job，以便在将其推送到 snap 商店之前完成剩餘的 snap 任務。
留着 .snap 包
為了測試我們在工作流示例中使用的 .snap 軟體包，我們需要一種在建構的時候持久儲存 snap 的方法。在這裡我将提供兩種方法：
artifact —— 在運作 build 任務的時候我們可以将 snaps 儲存為一個 circleci 的 artifact(lctt 譯注：artifact 是 snapcraft.yaml 中的一個 plugin-specific 關鍵字)，然後在接下來的任務中檢索它。circleci 工作流有自己處理共享 artifact 的方式，相關資訊可以在 這裡 找到。
snap 商店通道 —— 當釋出 snap 軟體包到 snap 商店時，有多種通道可供我們選擇。将 snap 的主分支釋出到 edge 通道以供内部或者使用者測試已經成為一種常見做法。我們可以在 build 任務中完成這些工作，然後接下來的的任務就可以從 edge 通道來安裝建構好的 snap 軟體包。
第一種方法速度更快，并且它還可以在 snap 軟包上傳到 snap 商店供使用者甚至是測試使用者使用之前對 snap 進行驗收測試。第二種方法的好處是我們可以從 snap 商店安裝 snap，這也是 ci 運作期間的測試項之一。
snap 商店的身份驗證
snapcraft-config-generator.py 腳本可以生成商店證書并将其儲存到 .snapcraft/snapcraft.cfg 中(注意：在運作公共腳本之前一定要對其進行檢查)。如果覺得在你倉庫中使用明文來儲存這個檔案不安全，你可以用 base64 編碼該檔案，并将其存儲為一個私有環境變量，或者你也可以對檔案 進行加密，并将密鑰存儲在一個私有環境變量中。
下面是一個示例，将商店證書放在一個加密的檔案中，并在 deploy 環節中使用它将 snap 釋出到 snap 商店中。
- deploy:
name: push to snap store
command: |
openssl aes-256-cbc -d -in .snapcraft/snapcraft.encrypted -out .snapcraft/snapcraft.cfg -k $key
/snap/bin/snapcraft push *.snap
除了 deploy 任務之外，工作流示例同之前的一樣， deploy 任務隻有當驗收測試任務通過時才會運作。
更多的資訊
alan pope 在 論壇中發的文章：“popey” 是 canonical 的員工，他在 snapcraft 的論壇上寫了這篇文章，并啟發作者寫了這篇博文。
snapcraft 網站： snapcraft 官方網站。
snapcraft 的 circleci bug 報告：在 launchpad 上有一個開放的 bug 報告頁面，用來改善 circleci 對 snapcraft 的支援。同時這将使這個過程變得更簡單并且更“正式”。期待您的支援。
怎麼使用 circleci 建構 nextcloud 的 snap：這裡有一篇題為 “複雜應用的持續驗收測試” 的博文，它同時也影響了這篇博文。
作者：ricardo feliciano
來源：51cto