本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 了解 CI/CD
<a name="understanding-cicd"></a>

持續整合和持續交付 (CI/CD) 是自動化軟體版本生命週期的程序。在某些情況下，CI/CD 中的 *D* 也可以表示*部署*。當您將變更發佈至生產環境時，就會發生*持續交付*與*持續部署*之間的差異。透過持續交付，在提升生產變更之前，需要手動核准。持續部署在整個管道中具有不間斷的流程，不需要明確核准。由於此策略討論一般 CI/CD 概念，因此提供的建議和資訊適用於持續交付和持續部署方法。

CI/CD 會自動化傳統上從遞交取得新程式碼到生產環境所需的許多或所有手動程序。CI/CD 管道包含來源、建置、測試、預備和生產階段。在每個階段中，CI/CD 管道會佈建部署或測試程式碼所需的任何基礎設施。透過使用 CI/CD 管道，開發團隊可以對程式碼進行變更，然後自動測試並推送至部署。

讓我們先檢閱基本 CI/CD 程序，再討論您可以刻意或無意中偏離完全 CI/CD 的一些方式。下圖顯示每個階段中的 CI/CD 階段和活動。



![\[CI/CD 程序的五個階段，以及每個階段的活動和環境。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)


## 關於持續整合
<a name="about-continuous-integration"></a>

持續整合發生在程式碼儲存庫中，例如 中的 Git 儲存庫GitHub。您會將單一主要分支視為程式碼基礎的真實來源，並建立短期分支以進行功能開發。當您準備好將功能部署到上層環境時，您可以將功能分支整合到主要分支。特徵分支永遠不會直接部署到上層環境。如需詳細資訊，請參閱本指南中的 [以主體為基礎的方法](fully-cicd-process-differences.md#trunk-based-approach)。

*持續整合程序*

1. 開發人員會從主分支建立新的分支。

1. 開發人員會在本機進行變更、建置和測試。

1. 當變更準備就緒時，開發人員會建立[提取請求](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub 文件），以主分支做為目的地。

1. 系統會檢閱程式碼。

1. 當程式碼獲得核准時，它會合併到主分支。

## 關於持續交付
<a name="about-continuous-delivery"></a>

持續交付發生在隔離的環境中，例如開發環境和生產環境。每個環境中發生的動作可能有所不同。通常，其中一個第一階段用於在繼續之前更新管道本身。部署的最終結果是，每個環境都會以最新的變更進行更新。用於建置和測試的開發環境數量也有所不同，但我們建議您至少使用兩個。在管道中，每個環境都會依其重要性順序更新，並以最重要的環境做為結尾，也就是生產環境。

*持續交付程序*

管道的持續交付部分會透過從來源儲存庫的主分支提取程式碼並將其傳遞至建置階段來啟動。儲存庫的基礎設施即程式碼 (IaC) 文件概述了在每個階段中執行的任務。雖然使用 IaC 文件不是強制性的，但[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html)強烈建議使用 IaC 服務或工具，例如 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)或 。最常見的步驟包括：

1. 單位測試

1. 程式碼建置

1. 資源佈建

1. 整合測試

如果管道中的任何階段發生任何錯誤或任何測試失敗，目前階段會回復到其先前的狀態，且管道會終止。後續變更必須在程式碼儲存庫中開始，並執行完整 CI/CD 程序。

# CI/CD 管道的測試
<a name="tests-for-cicd-pipelines"></a>

部署管道中常用的兩種自動化測試類型是*單元測試*和*整合測試*。不過，您可以在程式碼基礎和開發環境中執行許多類型的測試。[AWS 部署管道參考架構](https://pipelines.devops.aws.dev/application-pipeline/)定義了下列類型的測試：
+ **單元測試** – 這些測試會建置並執行應用程式程式碼，以確認其效能符合預期。它們模擬程式碼基礎中使用的所有外部相依性。單元測試工具的範例包括 [JUnit](https://junit.org/)、[Jest](https://jestjs.io/) 和 [pytest](https://pytest.org/)。
+ **整合測試** – 這些測試會針對佈建的測試環境進行測試，驗證應用程式是否符合技術需求。整合測試工具的範例包括 [Cucumber](https://cucumber.io/)、[vRest NG](https://vrest.io/) 和 [integ-tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) （適用於 AWS CDK)。
+ **接受測試** – 這些測試會針對佈建的測試環境進行測試，驗證應用程式是否符合使用者需求。接受測試工具的範例包括 [Cypress](https://cypress.io/) 和 [Selenium](https://selenium.dev/)。
+ **合成測試** – 這些測試會在背景中持續執行，以產生流量並驗證系統是否正常運作。合成測試工具的範例包括 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 和 [Dynatrace Synthetic Monitoring](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/)。
+ **效能測試** – 這些測試會模擬生產容量。他們會判斷應用程式是否符合效能需求，並將指標與過去的效能進行比較。效能測試工具的範例包括 [Apache JMeter](https://jmeter.apache.org/)、[Locust](https://locust.io/) 和 [Gatling](https://gatling.io/)。
+ **彈性測試** – 這些測試也稱為*混沌測試*，會將失敗注入環境，以識別風險區域。接著會將注入失敗的期間與沒有失敗的期間進行比較。彈性測試工具的範例包括 [AWS Fault Injection Service](https://aws.amazon.com/fis/)和 [Gremlin](https://www.gremlin.com/)。
+ **靜態應用程式安全測試 (SAST)** – 這些測試會分析安全性違規的程式碼，例如 [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection) 或[跨網站指令碼 (XSS)](https://owasp.org/www-community/attacks/xss/)。SAST 工具的範例包括 [Amazon CodeGuru](https://aws.amazon.com/codeguru/)、[SonarQube](https://www.sonarqube.org/) 和 [Checkmarx](https://checkmarx.com/)。
+ **動態應用程式安全測試 (DAST)** – 這些測試也稱為*滲透測試*或*筆測試*。它們可識別佈建測試環境中的漏洞，例如 SQL Injection 或 XSS。DAST 工具的範例包括 [Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) 和 [HCL AppScan](https://www.hcltechsw.com/appscan)。如需詳細資訊，請參閱[滲透測試](https://aws.amazon.com/security/penetration-testing/)。

並非所有完全 CI/CD 管道都會執行所有這些測試。不過，管道至少應在程式碼基礎上執行單元測試和 SAST 測試，以及在測試環境中進行整合和接受測試。

# CI/CD 管道的指標
<a name="metrics-for-cicd-pipelines"></a>

根據[AWS 部署管道參考架構](https://pipelines.devops.aws.dev/application-pipeline/)，您至少應該追蹤 CI/CD 管道的下列四個指標：
+ **前置時間** – 單一遞交一路投入生產所需的平均時間。我們建議您針對 1 小時到 1 天的前置時間，視您的使用案例而定。
+ **部署頻率** – 指定期間內的生產部署數量。我們建議您針對每天多次到每週兩次的部署頻率，視您的使用案例而定。
+ 平均**故障間隔時間 (MTBF)** – 成功管道開始與失敗管道開始之間的平均時間。我們建議以盡可能高的 MTBF 為目標。如需詳細資訊，請參閱[增加 MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html)。
+ **復原的平均時間 (MTTR)** – 從失敗管道開始到下一個成功管道開始的平均時間。我們建議以盡可能低的 MTTR 為目標。如需詳細資訊，請參閱[降低 MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)。

這些指標可協助團隊追蹤其成為完整 CI/CD 的進度。團隊應與組織的利益相關者就最佳目標進行公開討論。情況和需求因組織而異，甚至因團隊而異。

請務必記住，快速、劇烈的變更通常會增加發生問題的風險。設定目標以瞄準小型增量改進。完整 CI/CD 管道的常見最佳前置時間不到 3 小時。從 5.2 天的前置時間開始的團隊，目標應該是每幾週減少一天。此團隊達到一天或更少的前置時間後，他們可以留在那裡幾個月，並只有在團隊和組織利益相關者認為有必要時，才能進入更積極的前置時間。