2025年02月26日玄貓（BlackCat）

Node.js 專案 CI/CD 自動化佈署實踐

本文探討如何利用 Ansible 和 Bitbucket Pipelines 實作 Node.js 專案的自動化佈署，涵蓋流程建置、Pipeline 設定、最佳實踐以及 Azure CI/CD 能力介紹，並提供程式碼範例和流程圖，闡述持續整合與持續交付/佈署的精髓，協助團隊提升開發效率和軟體品質。

Web 開發 DevOps

CI/CD Ansible Bitbucket Pipelines Node.js Docker 自動化佈署

Ansible 與 Bitbucket Pipelines 的結合，為 Node.js 專案的自動化佈署提供了高效且可靠的解決方案。透過 Ansible 定義佈署任務，從程式碼更新、依賴管理到伺服器重啟，都能精確控制。Bitbucket Pipelines 則負責組態 Docker 容器，實作無縫的佈署流程。此方案能有效減少佈署錯誤、縮短交付時間，並提升團隊的開發效率。文章也深入探討 CI/CD 的核心概念、實踐方法及組織結構建議，並以 Azure 平臺的 CI/CD 服務為例，說明如何整合 CI/CD 流程，最終實作軟體開發流程的自動化和效率提升。

自動化佈署在CI/CD中的關鍵作用：以Node.js專案為例

在現代軟體開發中，自動化工具的整合對於提升開發效率和可靠性至關重要。Ansible作為一款強大的自動化工具，在伺服器管理任務中扮演著關鍵角色。結合Bitbucket Pipelines，本案例研究深入探討了它們在Node.js專案中的協同作用。

打造無縫佈署流程

自動化Node.js專案的佈署可以顯著提高效率並減少關鍵任務中的錯誤。無論是程式碼更新、依賴管理、資料函式庫遷移還是伺服器重啟，Ansible都能精確定義佈署任務。同時，Bitbucket Pipelines組態並啟動Docker容器以實作無縫佈署。

Bitbucket Pipelines組態範例

以下是一個針對Node.js專案的Bitbucket Pipelines組態範例（bitbucket-pipelines.yml）：

image: node:14

pipelines:
  branches:
    main:
      - step:
          name: deploy to prod
          deployment: Production
          caches:
            - npm
          script:
            - npm install -g ansible
            - cd ansible
            - ansible-playbook -i ./hosts deploy.yaml

此組態指定使用Node.js 14的Docker映像，並在主分支上觸發佈署。它利用快取機制儲存Ansible安裝，以節省構建時間。

設定Pipeline：打造無縫整合流程

步驟1：新增bitbucket-pipelines.yml檔案至儲存函式庫根目錄

image: node:14

pipelines:
  branches:
    main:
      - step:
          name: deploy to prod
          deployment: Production
          caches:
            - npm
          script:
            - npm install -g ansible
            - cd ansible
            - ansible-playbook -i ./hosts deploy.yaml

根據專案需求和結構調整內容。

步驟2：組態儲存函式庫設定以啟用Bitbucket Pipelines

導航至Bitbucket上的儲存函式庫。
點選左側選單中的「設定」。
在「Pipelines」下，確保為儲存函式庫啟用了該功能。

步驟3：產生SSH金鑰對以實作Ansible的SSH連線

在儲存函式庫設定中找到「SSH金鑰」部分。
點選「產生金鑰」以建立新的SSH金鑰對。
此金鑰對將用於Bitbucket Pipelines與佈署伺服器之間的安全通訊。

步驟4：新增伺服器指紋至Known Hosts

取得佈署伺服器的指紋（可從伺服器的SSH組態中取得或使用ssh-keyscan命令檢索）。
在儲存函式庫設定的「SSH金鑰」部分，滾動至「Known Hosts」。
在「主機位址」欄位中輸入伺服器的主機名稱。
點選「擷取」按鈕以取得指紋。
最後，點選「新增主機」按鈕將伺服器新增至Known Hosts。

步驟5：測試佈署

對程式碼進行更改並將其推播至主分支。
觀察Bitbucket Pipelines是否自動觸發在bitbucket-pipelines.yml檔案中定義的佈署流程。
在Bitbucket介面中監控流程執行情況。

步驟6：使用[skip-ci]在提交訊息中防止自動佈署

若要在主分支上進行更改但阻止自動佈署，請在提交訊息中包含[skip-ci]。
例如：git commit -m "修復錯誤 [skip-ci]"。
這確保CI/CD流程不會因本次提交而被觸發。

自動化佈署Node.js專案的優勢

透過Ansible和Bitbucket Pipelines的協同作用，本案例展示了一種強大的持續交付設定。自動化佈署流程可以節省時間並減少錯誤，從而提高開發效率和可靠性。

圖表翻譯：

此圖示展示了自動化佈署流程。首先檢查程式碼是否有更新。如果有更新，則執行Ansible佈署指令碼；如果沒有更新，則結束佈署流程。接著，組態Docker容器並啟動服務，最後完成佈署流程。這個流程清晰地展示了自動化佈署中的關鍵步驟和條件分支邏輯。

自動化佈署的最佳實踐

持續整合與持續佈署（CI/CD）： 自動化測試、構建和佈署流程，以提高軟體交付的速度和品質。
基礎設施即程式碼（IaC）： 使用工具如Ansible、Terraform來管理和組態基礎設施，以實作環境的一致性和可重複性。
容器化： 利用Docker等容器技術，實作應用程式的標準化和隔離，提高佈署的效率和可靠性。
監控與反饋： 建立完善的監控系統和反饋機制，及時發現和解決佈署過程中的問題。

自動化佈署與持續整合/持續佈署（CI/CD）實踐

在現代軟體開發中，自動化佈署和持續整合/持續佈署（CI/CD）已成為提升開發效率和軟體品質的關鍵實踐。本文將深入探討如何使用Ansible進行Node.js專案的自動化佈署，並介紹Azure的CI/CD能力。

使用Ansible自動化佈署Node.js專案

Ansible是一種流行的自動化工具，可用於簡化佈署流程。以下是使用Ansible佈署Node.js專案的步驟：

1. 設定SSH存取

首先，需要在本地環境中設定SSH存取。編輯~/.ssh/config檔案，新增以下內容：

Host yourserver
  User root
  Port 22

接著，設定無密碼存取，使用SSH金鑰：

# 生成SSH金鑰對
ssh-keygen

# 設定無密碼存取
ssh-copy-id root@yourserver

2. 使用Ansible佈署Node.js專案

複製Ansible範本倉函式庫

git clone https://example.com/nodejs-ansible-deploy.git
cd nodejs-ansible-deploy

自定義Ansible Playbooks
根據需求修改ansible目錄中的Playbooks。
更新Hosts檔案
編輯hosts檔案，新增伺服器資訊：
```
[yourserver]
ansible_ssh_user=root
```

執行Ansible Playbooks

執行以下命令以組態伺服器並佈署Node.js專案：

ansible-playbook -i hosts ansible/system.yaml
ansible-playbook -i hosts ansible/packages.yaml
ansible-playbook -i hosts ansible/config_files.yaml
ansible-playbook -i hosts ansible/postgresql.yaml
ansible-playbook -i hosts ansible/deploy.yaml

在此過程中，Ansible將執行諸如安裝必要套件、組態NGINX和uWSGI、建立PostgreSQL資料函式庫以及佈署Node.js專案等任務。

3. 更新Node.js專案

推播變更到Git儲存函式庫
```
git push origin master
```
執行Ansible Playbook更新專案
```
ansible-playbook -i hosts ansible/deploy.yaml
```
Playbook將擷取倉函式庫的最新變更、更新相依性、遷移資料函式庫、收集靜態檔案並重新啟動uWSGI。

4. 使用Bitbucket Pipelines實作持續交付

推播變更到Bitbucket倉函式庫
推播變更將觸發Bitbucket Pipelines。

組態Bitbucket Pipelines使用Ansible

編輯bitbucket-pipelines.yml檔案：

image: python:2.7.16

pipelines:
  branches:
    master:
      - step:
          name: Deploy to Production
          caches:
            - pip
          script:
            - pip install ansible==2.8.0
            - cd ansible
            - ansible-playbook -i ../hosts deploy.yaml

Azure的CI/CD能力

Azure提供了一套開發者服務，包括Azure DevOps Services、Azure Repos、Azure Pipelines、Azure Artifacts和Azure Deploy，以實作CI/CD。

CI/CD實踐

持續整合（CI）
CI是一種軟體開發方法論，開發者頻繁地將程式碼變更整合到中央倉函式庫中，觸發自動化建置和測試。
圖表翻譯：
此圖示展示了持續整合的流程。開發者提交程式碼後，系統自動進行建置和測試。如果測試透過，程式碼將被佈署到預生產環境；如果測試失敗，系統將通知開發者進行修正。
持續交付和持續佈署
持續交付強調自動化測試和佈署到預生產環境，而持續佈署則進一步自動化佈署到生產環境。
圖表翻譯：
此圖示展示了從持續整合到持續佈署的流程。持續整合是基礎，接著是持續交付，最終實作持續佈署，自動將軟體變更佈署到生產環境。

內容解密：

此程式碼定義了一個簡單的CI/CD流程控制函式cicd_pipeline。當有程式碼變更時，它會觸發CI流程，如果CI成功，則進一步觸發CD流程。函式trigger_ci和trigger_cd分別模擬了CI和CD的流程。這個簡單的範例展示瞭如何在程式碼中控制CI/CD流程的基本邏輯。

持續交付（CD）與持續佈署：軟體開發的新紀元

持續交付（Continuous Delivery，CD）是一種軟體開發方法論，透過自動化建置、測試和佈署流程，確保軟體變更能夠順暢地進入生產環境。相較於傳統的手動佈署方式，CD大幅提升了軟體開發的效率和品質。

持續交付與持續佈署的區別

許多人誤以為持續交付意味著每一次程式碼變更都會自動佈署到生產環境。然而，持續交付的核心在於確保每一次變更都經過充分測試，並且具備佈署到生產環境的準備。實際佈署的決定可以根據業務需求進行手動控制。

在持續交付的流程中，技術團隊可以建立嚴格的審核機制，確保每次佈署都經過授權和稽核。技術驗證在每次程式碼提交時進行，而佈署到生產環境的決定則轉變為商業決策，而非純粹的技術問題。

持續交付的優勢

持續交付為軟體開發團隊帶來多項顯著優勢，包括自動化流程、提高開發者生產力、提升程式碼品質，以及加快更新交付給客戶的速度。

自動化發布流程

透過持續交付，團隊的程式碼提交後會自動進行建置、測試和佈署準備。這不僅提升了軟體交付過程的效率和可靠性，也確保了流程的安全性和一致性。

提升開發者效率

持續交付實踐能夠提升團隊生產力，開發者可以專注於撰寫核心功能程式碼，而非浪費時間在複雜的整合和佈署問題上。透過自動化流程，開發者能夠更快速地獲得回饋，並及時修正錯誤。

提升程式碼品質

持續交付有助於在早期階段發現並解決程式錯誤，避免問題在後期變得更加複雜。自動化測試流程使得團隊能夠頻繁執行各種程式碼測試，從而提高程式碼的穩定性和安全性。

加速更新交付

持續交付使團隊能夠快速、定期地向客戶交付更新。透過CI/CD的實施，團隊能夠提升整體開發效率，加快功能和錯誤修復的發布速度。這使得企業能夠更靈活地應對市場變化、客戶需求和安全威脅。

實作CI/CD

在企業中匯入CI/CD模型需要逐步實踐。首先，建議從小規模開始，迭代式地建立CI/CD流程，而非試圖一次性建立完整的自動化流程。

CI/CD流程視覺化

CI/CD流程類別似於一個Pipeline（Pipeline），新程式碼在進入流程後會經過多個階段的測試，最終成為可佈署到生產環境的程式碼。對於初次匯入CI/CD的企業，建議從簡單的流程開始，逐步擴充套件和完善。

圖表翻譯：

此圖示展示了一個典型的CI/CD流程。首先，開發者提交程式碼，接著系統自動進行建置和測試。如果測試透過，程式碼會被佈署到預生產環境進行進一步驗證；如果測試失敗，則會觸發錯誤回報機制。整個流程確保了程式碼的品質和佈署的可靠性。

組織轉型之路

轉型為支援CI/CD的組織是一段持續的旅程，需要逐步推進。首先從持續整合（CI）開始，逐步建立更完善的持續交付（CD）流程。過程中，企業需要不斷評估和最佳化其CI/CD流程，以適應不斷變化的業務需求和技術環境。

實務應用

在Azure環境中實施CI/CD，需要考慮企業的具體需求和現有基礎設施。建議參考Azure生態系統中的專家資源和相關檔案，以獲得更全面的指導。

程式碼範例：自動化佈署指令碼

import os

def deploy_to_production():
 """佈署程式碼到生產環境"""
 try:
 # 從版本控制系統取得最新程式碼
 os.system("git pull origin main")
 
 # 執行建置和測試
 os.system("npm install")
 os.system("npm test")
 
 # 佈署到生產環境
 os.system("npm run deploy")
 
 print("佈署成功")
 except Exception as e:
 print(f"佈署失敗: {e}")

if __name__ == "__main__":
 deploy_to_production()

內容解密：

此指令碼示範了一個簡單的自動化佈署流程。首先，它從版本控制系統取得最新程式碼，接著執行依賴安裝和測試，最後佈署到生產環境。透過這種自動化流程，可以大幅減少手動佈署的錯誤和工作量。

持續整合與持續交付/佈署（CI/CD）實踐

在現代軟體開發中，持續整合（CI）與持續交付/佈署（CD）已成為提升開發效率和軟體品質的重要實踐。本文將深入探討CI/CD的核心概念、實踐方法以及組織結構建議，幫助讀者建立完善的CI/CD流程。

持續整合：打造堅實的基礎

持續整合是CI/CD旅程的第一步，強調開發者頻繁地將程式碼提交到中央儲存函式庫（如CodeCommit或GitHub），並將所有變更合併到指定的釋出分支。這個過程鼓勵開發者保持程式碼的更新，避免孤立的程式碼倉儲。

圖表翻譯：

此圖示展示了持續整合的基本流程。開發者提交程式碼後，自動觸發建置和單元測試。若測試透過，程式碼將被合併到釋出分支；若測試失敗，開發者需修復程式碼後重新提交。此流程確保了程式碼的品質和整合的順暢。

在CI實踐中，開發者應在早期開發階段就建立單元測試，並在提交程式碼前執行這些測試，以早期發現錯誤。提交程式碼後，工作流程引擎會監控分支並觸發建置工具，執行程式碼建置和單元測試。這個過程還可以整合其他品品檢查，如單元測試覆寫率、程式碼風格檢查和靜態分析。

持續交付：建立預發布環境

持續交付是CI/CD的下一步，涉及將應用程式碼佈署到一個與生產環境相似的預發布環境，並執行額外的功能測試。

圖表翻譯：

此圖示展示了持續交付的流程。首先從儲存函式庫取得最新的程式碼，接著佈署到預發布環境並執行功能測試。若測試透過，則準備佈署到生產環境；若測試失敗，則需要修復問題並重新佈署到預發布環境進行測試。

預發布環境可以是預先建立的靜態環境，也可以是根據基礎設施即程式碼（IaC）動態建立的環境。這種環境應該盡可能地模擬生產環境，以確保測試的準確性。

持續佈署：自動化佈署到生產環境

持續佈署是CI/CD的最終階段，涉及將經過測試的程式碼自動佈署到生產環境。

圖表翻譯：

此圖示展示了持續佈署的流程。當預發布環境的測試透過後，系統會自動將程式碼佈署到生產環境。佈署後，系統會持續監控生產環境的狀態。若發現問題，可以選擇回復到之前的版本或進行修復。

組織結構建議

Azure建議建立三個開發團隊來支援CI/CD環境：應用程式團隊、基礎設施團隊和工具團隊。

@startuml
skinparam backgroundColor #FEFEFE

title Node.js 專案 CI/CD 自動化佈署實踐

|開發者|
start
:提交程式碼;
:推送到 Git;

|CI 系統|
:觸發建置;
:執行單元測試;
:程式碼品質檢查;

if (測試通過?) then (是)
    :建置容器映像;
    :推送到 Registry;
else (否)
    :通知開發者;
    stop
endif

|CD 系統|
:部署到測試環境;
:執行整合測試;

if (驗證通過?) then (是)
    :部署到生產環境;
    :健康檢查;
    :完成部署;
else (否)
    :回滾變更;
endif

stop

@enduml

圖表翻譯：

此圖示展示了支援CI/CD的三大開發團隊及其主要職責。應用程式團隊負責開發應用程式功能，基礎設施團隊管理基礎設施即程式碼，工具團隊則維護CI/CD工具鏈。這種分工有助於提高開發效率和CI/CD流程的可靠性。

成熟度與未來發展

隨著組織的成長，CI/CD模型會不斷演進，引入更多改進措施，如增加更多預發布環境以滿足特定的測試需求（如效能測試、合規性測試、安全性測試和使用者介面測試）、對基礎設施和組態程式碼進行單元測試、與其他系統和流程整合（如程式碼審查、問題追蹤和事件通知）、整合資料函式庫架構遷移，以及增加稽核和業務審批步驟。

DevOps是一個持續改進的過程，而非終點。團隊會不斷收集關於CI/CD流程的反饋，並透過協作來提高流程的速度、規模、安全性和可靠性。