本文主要介紹了Node.js應用如何構建并部署到ECS。
背景意義
如果您的業務使用Node.js進行開發、使用二進制的制品形式進行交付，并且制品最終會運行到ECS或者自有主機上，那么本文檔可以幫您實現研發流程的協同自動化。
用戶訴求
一般來說，用戶使用主機部署場景如下：
對源代碼進行一定的質量檢測，比如單元測試，代碼掃描。
將源代碼構建成為可交付的制品，比如二進制文件。
對制品進行測試環境驗證。
使用完成驗證的制品進行線上部署。
上述活動需要有不同角色的參與：開發、測試、運維。如何保證不同參與者可以使用統一的交付流程來進行協作，是云效Flow交付流水線要解決的主要問題。
解決方案
結合云效持續交付流水線和主機部署的能力，為應用持續交付提供了很好的基礎保障，如圖：
開發者提交代碼變更到代碼庫，云效在監聽著代碼庫的變動，一旦代碼發生變化，將自動觸發云效持續部署流水線一次構建任務的運行，包括代碼檢查、構建、測試部署、測試驗證和生產部署等過程。其中，在構建完之后，生成制品包并自動上傳至倉庫，在部署階段（測試環境的部署和生產環境的部署）時，再從制品倉庫中取得最新的版本，根據不同的部署策略通過主機部署到不同環境，這里資源可以是阿里云或者自建主機資源。
操作實踐
模板構建并配置流水線
進入云效流水線Flow，點擊右上角新建流水線，選擇“Node.js·測試、構建、部署到阿里云ECS/自有主機”模板后點擊創建。
創建流水線之后點擊添加流水線源，選擇Flow提供的示例代碼源，并進行添加。
修改Node.js構建任務，在構建物上傳步驟增加一個打包路徑，填入app-configs/bin/appctl.sh。這個文件存在于代碼庫中appctl.sh，用于后續的主機部署。
接下來配置主機部署任務，在制品下拉框中選擇前面構建上傳步驟歸檔的那個制品。選擇需要部署的主機組（如無主機組，點擊新建主機組并參考主機組管理），然后配置部署腳本：
下載路徑：表示希望把構建上傳任務中的壓縮包下載到機器上的什么位置，在本例的值為：/home/admin/app/package.tgz
執行用戶：希望以是哪個用戶的身份進行腳本執行，本例的值為：root
部署腳本：在機器上執行腳本的具體內容，本例的值為：
mkdir -p /home/admin/application/ && tar -zxvf /home/admin/app/package.tgz -C /home/admin/application/ && cd /home/admin/application/ && ./app-configs/bin/appctl.sh restart
添加人工審核機制
如果需要保證只有經過審批的制品才能進入部署環境，則還需要添加一個人工卡點，在上述流水線主機部署前添加如下任務：
在人工卡點任務中勾選需要添加的驗證人并點擊確定。
流水線運行
配置完畢，點擊保存并運行觸發流水線：
掃描、單測及構建上傳的任務自動完成，并停在了卡點上：
點擊驗證通過，流水線會進入主機部署的任務，點擊部署詳情可以看到更多部署信息：
點擊日志，可以看到執行的日志詳情：
部署回滾
如果發布完成之后發現線上服務有問題，則需要快速回滾。云效Flow提供了通過歷史版本直接進行回滾的能力。
在流水線運行頁面點擊部署歷史，然后選擇相應部署任務，便可以看到該部署任務所有部署成功記錄。
點擊版本#3的回滾，即可回滾到該版本。
流水線初次部署時頁面上可能不顯示部署歷史頁，此時嘗試刷新頁面可以解決。
通知
為了更好進行協作，Flow提供了通知能力在流水線不同的生命周期節點上進行通知。一般來講開發團隊會關心部署的成功和失敗，那么可以將該事件推送到團隊的釘釘群中，配置方式如下，點擊添加插件，選擇釘釘機器人通知，填入webhook地址，再次運行之后，就會收到相應的通知，具體請參考釘釘機器人發送群消息。
結語
通過以上的操作流程，就可以建立一條協同多角色的流水線，參考以下文檔了解更多內容：