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

# 完整 CI/CD 程序有何不同
<a name="fully-cicd-process-differences"></a>

CI/CD 管道使用現代*幹線型工作流程*，開發人員會將小型、頻繁的更新合併到透過 CI/CD 管道的 CD 部分建置和測試的主分支 （或*幹*線）。此工作流程已取代 *Gitflow 工作流程*，其中開發和發行分支以發行排程分隔。在許多組織中，Gitflow 仍然是熱門的版本控制和部署方法。不過，它現在被視為舊版，整合到 CI/CD 管道可能具有挑戰性。

對於許多組織而言，從 Gitflow 工作流程到以幹線為基礎的工作流程的轉換尚未完成，結果是它們在過程中卡在某個位置，永遠不會完全遷移到 CI/CD。以某種方式來說，其管道最終會追蹤到舊版工作流程的特定殘差，並卡在過去和現在之間的轉換狀態。檢閱 Git 工作流程中的差異，然後了解使用舊版工作流程如何影響下列項目：
+ [環境完整性](environment-integrity.md)
+ [推出](releases.md)
+ [安全](security.md)

為了更輕鬆地識別現代組態中舊版 Git 工作流程的殘差，讓我們比較 [Gitflow](#gitflow-approach) 與現代、以[幹線為基礎的](#trunk-based-approach)方法。

## Gitflow 方法
<a name="gitflow-approach"></a>

下圖顯示 Gitflow 工作流程。Gitflow 方法使用多個分支來同時追蹤多個不同版本的程式碼。您可以在開發人員仍在處理目前版本的程式碼時，將應用程式的更新版本安排在未來某個時間點。主體型儲存庫可以使用特徵標記來完成此操作，但預設會內建於 Gitflow。



![具有功能、開發、發行和 Hotfix 分支的 Gitflow 工作流程](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)


Gitflow 方法的一個結果是應用程式環境通常不同步。在標準 Gitflow 實作中，開發環境會反映程式碼的目前狀態，而生產前環境和生產環境仍會在最新版本的程式碼基礎狀態上保持凍結狀態。

當瑕疵出現在生產環境中時，這會讓情況更為複雜，因為開發人員在未公開未發行的功能的情況下，無法將執行的程式碼基底合併到生產環境中。Gitflow 處理這種情況的方式是使用 Hotfix。從發行分支建立 Hotfix 分支，然後直接部署到上層環境。然後，Hotfix 分支會合併到開發分支中，以保持程式碼為最新狀態。

## 以主體為基礎的方法
<a name="trunk-based-approach"></a>

下圖顯示以幹線為基礎的工作流程。在以幹線為基礎的工作流程中，開發人員會在本機的特徵分支中建置和測試特徵，然後將這些變更合併到主分支中。然後，主要分支會依序建置到開發環境、生產前環境和生產環境中。單元和整合測試會在每個環境之間進行。



![具有特徵分支和主分支的幹線型工作流程。](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)


使用此工作流程，所有環境都會操作相同的程式碼基底。上層環境不需要 Hotfix 分支，因為您可以在主要分支中實作變更，而無需公開未發行的功能。主要分支一律假設穩定、沒有瑕疵，並準備好發行。這可協助您將其整合為 CI/CD 管道的來源，以便透過管道中的所有環境自動測試和部署您的程式碼基礎。