## 前言

首先介紹下在本文出現的幾個比較重要的概念：

> **函式計算（Function Compute）**：[函式計算](https://statistics.functioncompute.com/?title=Serverless%20%E5%AE%9E%E6%88%98%20%E2%80%94%E2%80%94%20Funcraft%20%2B%20OSS%20%2B%20ROS%20%E8%BF%9B%E8%A1%8C%20CI%2FCD&author=%E5%80%9A%E8%B4%A4&url=http%3A%2F%2Ffc.console.aliyun.com%2F%3Ffctraceid%3DYXV0aG9yJTNEJUU1JTgwJTlBJUU4JUI0JUE0JTI2dGl0bGUlM0RTZXJ2ZXJsZXNzJTIwJUU1JUFFJTlFJUU2JTg4JTk4JTIwJUUyJTgwJTk0JUUyJTgwJTk0JTIwRnVuY3JhZnQlMjAlMkIlMjBPU1MlMjAlMkIlMjBST1MlMjAlRTglQkYlOUIlRTglQTElOEMlMjBDSSUyRkNE&src=article)是一個事件驅動的服務，透過函式計算，使用者無需管理伺服器等執行情況，只需編寫程式碼並上傳。函式計算準備計算資源，並以彈性伸縮的方式執行使用者程式碼，而使用者只需根據實際程式碼執行所消耗的資源進行付費。函式計算更多資訊[參考](https://help.aliyun.com/product/50980.html)。
> **Funcraft**：Funcraft 是一個用於支援 Serverless 應用部署的工具，能幫助您便捷地管理函式計算、API 閘道器、日誌服務等資源。它透過一個資源配置檔案（template.yml），協助您進行開發、構建、部署操作。Fun 的更多文件[參考](https://github.com/aliyun/fun)。
> **OSS**: 物件儲存。海量、安全、低成本、高可靠的雲端儲存服務，提供99.9999999999%的資料可靠性。使用RESTful API 可以在網際網路任何位置儲存和訪問，容量和處理能力彈性擴充套件，多種儲存型別供選擇全面最佳化儲存成本。
> **ROS**：資源編排（ROS）是一種簡單易用的雲端計算資源管理和自動化運維服務。使用者透過模板描述多個雲端計算資源的依賴關係、配置等，並自動完成所有資源的建立和配置，以達到自動化部署、運維等目的。編排模板同時也是一種標準化的資源和應用交付方式，並且可以隨時編輯修改，使基礎設施即程式碼（Infrastructure as Code）成為可能。
> **CI/CD**: CI/CD 是一種透過在應用開發階段引入自動化來頻繁向客戶交付應用的方法。CI/CD 的核心概念是持續整合、持續交付和持續部署。
![](https://data-analysis.cn-shanghai.log.aliyuncs.com/logstores/article-logs/track_ua.gif?APIVersion=0.6.0&title=Serverless%20%E5%AE%9E%E6%88%98%20%E2%80%94%E2%80%94%20Funcraft%20%2B%20OSS%20%2B%20ROS%20%E8%BF%9B%E8%A1%8C%20CI%2FCD&author=%E5%80%9A%E8%B4%A4&src=article)

## 目標

本文打算以一個簡單的函式計算專案為例，在此基礎上編寫測試用例，進行配置，讓其支援 CI/CD 工作流程。實現如下四個小目標：

1. CI 被 git commit 提交觸發
2. 執行測試（單元、整合和端對端）
3. 函式打包上傳到 OSS
4. 透過 ROS 部署函式到 Staging 環境

## 工作流程圖

![image.png](https://img.alicdn.com/tfs/TB1ufMHr4z1gK0jSZSgXXavwpXa-902-424.png)

這裡以大家熟悉的 Github 倉庫為例，並結合 Travis CI 。當使用者往示例專案 push 或者 PR（Pull Request）時，會自動觸發 Travis CI 的工作任務，進行單元測試、構建打包和部署釋出。

## 示例專案

示例專案地址為：https://github.com/vangie/tz-time ，該專案是基於 FC Http trigger 實現的簡單 web 函式，訪問放函式是會返回指定時區的當前時間。專案目錄結構如下

```
tz-time
├── .funignore
├── .travis.yml
├── Makefile
├── bin
│   ├── delRosStack.sh
│   ├── deployE2EStack.sh
│   └── waitForServer.sh
├── deploy.log
├── index.e2e-test.js
├── index.integration-test.js
├── index.js
├── index.test.js
├── jest.config.e2e.js
├── jest.config.integration.js
├── package-lock.json
├── package.json
└── template.yml
```

部分檔案作用介紹：

* `.funignore`  - Funcraft 部署時忽然的檔案清單
* `.travis.yml` - Travis CI 配置檔案
* `index.js` - 函式入口檔案
* *.test.js - 單元測試相關檔案
* *.integraion-test.js - 整合測試相關檔案
* *.e23-test.js - 端對端測試相關檔案
* template.yml - ROS 描述檔案，用於描述函式和其他雲服務

## 自動化測試

測試通常非常如下三類：單元測試、整合測試和 E2E 測試。在函式計算場景下，這三類測試可以透過如下方法實現。

* 單元測試 - 使用 Mock 類測試函式，驗證輸入輸出引數
* 整合測試 - 使用 `fun local invoke/start` 模擬執行函式
* E2E 測試 - 使用 fun deploy 部署一套 test 環境，然後透過 fun invoke 進行模擬呼叫或者透過 curl 直接傳送

本例子只實現了單元測試，整合測試和 E2E 測試對於 travis 示例來說觸發方法類似，實現方法可以參見上面的方法提示進行配置。

### 單元測試

FC 函式的單元測試和普通的函式並無二致。採用熟悉的單元測試框架即可，本例中使用了 jest 進行測試。下面看看一個測試用例的程式碼片段

```javascript
jest.mock('moment-timezone');

const { tz } = require('moment-timezone');
const { handler } = require('./index');

const EXPECTED_DATE = '2018-10-01 00:00:00';
const TIMEZONE = 'America/New_York';

describe('when call handle', () => {
    it('Should return the expected date if the provied timezone exists', () => {
        const mockReq = {
            queries: {
                tz: TIMEZONE
            }
        }
        const mockResp = {
            setHeader: jest.fn(),
            send: jest.fn()
        }

tz.names = () => [TIMEZONE];
        tz.mockImplementation(() => {
            return {
                format: () => EXPECTED_DATE 
            }
        })

handler(mockReq, mockResp, null);

expect(mockResp.setHeader.mock.calls.length).toBe(1);
        expect(mockResp.setHeader.mock.calls[0][0]).toBe('content-type');
        expect(mockResp.setHeader.mock.calls[0][1]).toBe('application/json');

expect(mockResp.send.mock.calls.length).toBe(1);
        expect(mockResp.send.mock.calls[0][0]).toBe(JSON.stringify({
            statusCode: '200',
            message: `The time in ${TIMEZONE} is: ${EXPECTED_DATE}`
        }, null, '    '));

});
});
```

透過 jest.mock 對 moment-timezone 進行 mock，讓 tz 被呼叫的時候返回預先設定好的值，而不是一個動態變化的時間。

通常該類單元測試分為三步：

1. mock 依賴的值或者引數
2. 呼叫測試函式
3. 斷言返回結果和被呼叫的引數

如果依賴包不存在原生依賴（依賴 linux 下的可執行檔案或者 so 庫檔案）的使用 npm test 觸發測試即可，如果有原生依賴，那測試需要跑在 fun 提供的 sbox 模擬環境裡，使用如下命令觸發

```bash
fun install sbox -f tz-time --cmd 'npm install'
```

### 整合測試

本例子中的整合測試會藉助 fun local start 命令把函式在本地啟動起來，由於函式配置了 http trigger，所以可以透過 http 請求呼叫函式。

整合測試我們還是才是 jest 框架進行編寫，為了區別於單元測試檔案 `*.test.js` ，整合測試檔案使用 `.integration-test.js` 檔案字尾。為了讓 jest 命令獨立的跑整合測試用例而不是和單元測試混和在一起，需要編撰如下檔案 jest.config.integration.js

```javascript
module.exports = {
    testMatch: ["**/?(*.)integration-test.js"]
};
```

然後在 package.json 中配置 scripts

```javascript
"scripts": {
    "integration:test": "jest -c jest.config.integration.js"
}
```
於是可以透過執行 npm run integration:test 來執行整合測試。

然後在此基礎上在 Makefile 中新增 integration-test 目標：

```Makefile
funlocal.PID:
	fun local start & echo $$! > $@

integration-test: funlocal.PID 
	bin/waitForServer.sh http://localhost:8000/2016-08-15/proxy/tz-time/tz-time/
	npm run integration:test
	kill -2 `cat $ $@` 啟動 fun local 程式，並將程式 PID 寫入到目標同名檔案 funlocal.PID
* `bin/waitForServer.sh http://localhost:8000/2016-08-15/proxy/tz-time/tz-time/` 透過一個 url 測試 fun local 程式是否啟動完成。
* ``kill -2 `cat $ {
    it('without tz', (done) => {
        request(url, (error, response, data) => {
            if (error) {
                fail(error);
            } else {
                const resData = JSON.parse(data);
                expect(resData.statusCode).toBe(200);
                expect(resData.message).toContain('Asia/Shanghai');
            }
            done();
        });
    });
});
```

### 端對端測試

端對端測試和整合測試的測試用例非常的類似，區別在於測試的服務端，端對端測試部署一套真實的環境，整合測試透過 fun local 本地模擬。

本例中藉助 `fun deploy --use-ros` 部署一套環境，環境名稱為 `tz-e2e-` 字首帶上時間戳，這樣每次測試都會部署一套新的環境，不同環境之間相互不會影響。測試完成再透過 aliyun-cli 工具把 ROS 的 stack 刪除即可。

下面端對端測試的 Makefile 目標：

```Makefile
stack_name := tz-e2e-$(shell date +%s)

e2e-test:
	# deploy e2e 
	bin/deployE2EStack.sh $(stack_name)
	# run test
	npm run e2e:test
	# cleanup
	bin/delRosStack.sh $(stack_name)
```

* `bin/deployE2EStack.sh $(stack_name)` 負責部署一個新的 ROS stack。部署之前需要使用 fun package 構建交付物，具體如何構建交付物可以參考下一小節。
* `npm run e2e:test` 執行端對端測試
* `bin/delRosStack.sh $(stack_name)` 測試完成之後，清理部署的 ROS stack，會釋放掉響應的雲資源。

## 構建交付物

`fun package` 命令可被用於構建交付物，`fun package` 需要指定一個 OSS 的 bucket。fun package 命令會完成如下步驟：

1. 將程式碼編譯打包成 Zip 檔案。
2. 上傳程式碼包到 OSS bucket。
3. 生成新的檔案 template.packaged.yml，其中程式碼本地地址改為 OSS bucket 地址。

生成的 template.packaged.yml 檔案就是最終交付物，可以透過 fun deploy 命名進行部署。

## 持續部署

當構建環節生成了交付物以後，就可以透過 fun deploy 進行部署了。持續部署需要解決如下兩個問題：

1. 支援全新部署和升級部署
2. 一套資源描述支援部署多套，比如 test 環境、staging 環境和 production 環境。

`fun deploy` 藉助於 ROS，可以輕鬆的解決上述問題。

```bash
fun deploy --use-ros --stack-name tz-staging --assume-yes
```

其中：

* `--use-ros` 表示藉助於 ROS 進行部署，其工作機制是將 template.yml 推送到 ROS 服務，由 ROS 服務執行每個服務的新建和更新操作。如果沒有該引數，fun 就會在本地解析 template.yml，呼叫 API 進行資源建立。ROS 有個額外的好處是可以進行部署的回滾，失敗的時候能自動進行回滾。
* `--stack-name` 指定一個 stack 的名稱，stack 是 ROS 的概念，可以理解為一套環境。
* `--assume-yes` 用於無人值守模式，跳過確認提示。

注意，此處如果不指定引數 `--use-ros` ，fun deploy 會採用直接呼叫雲資源 API 進行部署， 這是 fun deploy 的預設部署方式，雖然也基本實現了冪等部署，但是僅支援部署有限的雲資源（FC、OTS、API Gateway等），遠不及 ROS 豐富，而且也沒法做到 ROS 已支援的回滾和一鍵刪除，所以此處不推薦。

## 小結

上面所有步驟的指令碼化配置可以參考 Makefile 和 .travis.yml 檔案。透過上述兩個檔案可以實現 Github 和 Travis CI 的聯動，實現基於程式碼提交觸發的 CI/CD。

本文講述了 FC 函式

1. 如何進行測試，特別是單元測試的自動化
2. 如何構建交付物，透過 fun package 將程式碼檔案上傳到 OSS Bucket，讓交付物程式設計一個文字描述檔案 template.packaged.yml
3. 如何持續部署，藉助於 ROS 部署多套環境，多次更新同一套環境。

## 參考閱讀

1. [原始碼示例專案 tz-time](https://github.com/vangie/tz-time)
2. [開發函式計算的正確姿勢 —— 使用 ROS 進行資源編排](https://yq.aliyun.com/articles/719104)
3. [Funcraft](https://github.com/alibaba/funcraft)
4. [Aliyun Serverless VSCode Extension](https://github.com/alibaba/serverless-vscode)

>“[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

Serverless 實戰 —— Funcraft + OSS + ROS 進行 CI/CD

相關文章