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

# 了解 DevOps 環境
<a name="understanding-the-devops-environments"></a>

若要了解分支策略，您必須了解每個環境中發生的目的和活動。建立數個環境可協助您將開發活動分成數個階段、監控這些活動，並防止意外發行未經核准的功能。您可以在 AWS 帳戶 每個環境中有一或多個 。

大多數組織都有幾個概述使用的環境。不過，環境數量可能因組織和軟體開發政策而異。此文件系列假設您有下列五個通用環境，這些環境橫跨您的開發管道，但它們可能由不同的名稱呼叫：
+ **沙盒** – 開發人員編寫程式碼、犯錯和執行概念驗證工作的環境。
+ **開發** – 一種環境，開發人員會整合其程式碼，以確認其可做為單一且具凝聚力的應用程式運作。
+ **測試** – 進行 QA 團隊或接受度測試的環境。團隊通常會在此環境中執行效能或整合測試。
+ **預備** – 生產前環境，您可以在此環境驗證程式碼和基礎設施在生產同等情況下如預期般執行。此環境已設定為盡可能類似於生產環境。
+ **生產** – 處理來自最終使用者和客戶流量的環境。

本節詳細說明每個環境。它還描述了每個環境的建置步驟、部署步驟和結束條件，以便您可以繼續進行下一個操作。下圖依序顯示這些環境。

![\[常見 DevOps 環境的順序\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [沙盒環境](sandbox-environment.md)
+ [開發環境](development-environment.md)
+ [測試環境](testing-environment.md)
+ [預備環境](staging-environment.md)
+ [生產環境](production-environment.md)

# 沙盒環境
<a name="sandbox-environment"></a>

*沙盒環境*是開發人員編寫程式碼、犯錯和執行概念驗證工作的地方。您可以從本機工作站或透過本機工作站上的指令碼部署到沙盒環境。

## 存取
<a name="access"></a>

開發人員應擁有沙盒環境的完整存取權。

## 建置步驟
<a name="build-steps"></a>

開發人員準備好將變更部署到沙盒環境時，會在其本機工作站上手動執行建置。

1. 使用 [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) 掃描敏感資訊

1. 填入原始碼

1. 如果適用，請建置和編譯原始程式碼

1. 執行單位測試

1. 執行程式碼涵蓋範圍分析

1. 執行靜態程式碼分析

1. 建置基礎設施即程式碼 (IaC)

1. 執行 IaC 安全分析

1. 擷取開放原始碼授權

1. 發佈建置成品

## 部署步驟
<a name="deployment-steps"></a>

如果您使用的是 Gitflow 或主體模型，則當`feature`分支成功建置在沙盒環境中時，部署步驟會自動啟動。如果您使用的是 GitHub Flow 模型，則需手動執行下列部署步驟。以下是沙盒環境中的部署步驟：

1. 下載已發佈的成品

1. 執行資料庫版本控制

1. 執行 IaC 部署

1. 執行整合測試

## 移至開發環境之前的期望
<a name="expectations-before-moving-to-the-development-environment"></a>
+ 在沙盒環境中成功建置`feature`分支
+ 開發人員已手動部署並測試沙盒環境中的功能

# 開發環境
<a name="development-environment"></a>

*開發環境*是開發人員將其程式碼整合在一起的地方，以確保所有程式碼都作為一個凝聚性應用程式運作。在 Gitflow 中，開發環境包含合併請求包含的最新功能，並準備好發佈。在 GitHub Flow 和 Trunk 策略中，開發環境被視為測試環境，而且程式碼基底可能不穩定且不適合部署到生產環境。

## 存取
<a name="access"></a>

根據最低權限原則指派許可。*最低權限*是授予執行任務所需的最低許可的安全最佳實務。開發人員對開發環境的存取應該比對沙盒環境的存取少。

## 建置步驟
<a name="build-steps"></a>

對`develop`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow) 建立合併請求會自動啟動建置。

1. 使用 [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) 掃描敏感資訊

1. 填入原始碼

1. 如果適用，請建置和編譯原始程式碼

1. 執行單位測試

1. 執行程式碼涵蓋範圍分析

1. 執行靜態程式碼分析

1. 建置 IaC

1. 執行 IaC 安全分析

1. 擷取開放原始碼授權

## 部署步驟
<a name="deployment-steps"></a>

如果您使用的是 Gitflow 模型，則在開發環境中成功建置`develop`分支時，部署步驟會自動啟動。如果您使用的是 GitHub Flow 模型或主體模型，則當針對`main`分支建立合併請求時，部署步驟會自動啟動。以下是開發環境中的部署步驟：

1. 從建置步驟下載已發佈的成品

1. 執行資料庫版本控制

1. 執行 IaC 部署

1. 執行整合測試

## 移至測試環境之前的期望
<a name="expectations-before-moving-to-the-testing-environment"></a>
+ 在開發環境中成功建置和部署`develop`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow)
+ 單位測試以 100% 通過
+ 成功的 IaC 建置
+ 已成功建立部署成品
+ 開發人員已執行手動驗證，以確認功能如預期般運作

# 測試環境
<a name="testing-environment"></a>

品質保證 (QA) 人員使用測試環境來驗證功能。它們會在完成測試後核准變更。當他們核准時，分支會移至下一個環境：預備。在 Gitflow 中，此環境及其上其他環境只能從`release`分支進行部署。`release` 分支是以包含計劃功能的`develop`分支為基礎。

## 存取
<a name="access"></a>

根據最低權限原則指派許可。開發人員對測試環境的存取應少於他們對開發環境的存取。QA 人員需要足夠的許可來測試功能。

## 建置步驟
<a name="build-steps"></a>

此環境中的建置程序僅適用於使用 Gitflow 策略時的錯誤修正。向`bugfix`分支建立合併請求會自動啟動建置。

1. 使用 [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) 掃描敏感資訊

1. 填入原始碼

1. 如果適用，請建置和編譯原始程式碼

1. 執行單位測試

1. 執行程式碼涵蓋範圍分析

1. 執行靜態程式碼分析

1. 建置 IaC

1. 執行 IaC 安全分析

1. 擷取開放原始碼授權

## 部署步驟
<a name="deployment-steps"></a>

在開發環境中部署之後，在測試環境中自動啟動`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow) 的部署。以下是測試環境中的部署步驟：

1. 在測試環境中部署`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow)

1. 暫停以進行指定人員的手動核准

1. 下載已發佈的成品

1. 執行資料庫版本控制

1. 執行 IaC 部署

1. 執行整合測試

1. 執行效能測試

1. 品質保證核准

## 移至預備環境之前的期望
<a name="expectations-before-moving-to-the-staging-environment"></a>
+ 開發和 QA 團隊已執行足夠的測試，以滿足組織的需求。
+ 開發團隊已透過`bugfix`分支解決任何發現的錯誤。

# 預備環境
<a name="staging-environment"></a>

*預備環境*設定為與生產環境相同。例如，資料設定的範圍和大小應與生產工作負載類似。使用預備環境來驗證程式碼和基礎設施是否如預期般運作。此環境也是商業使用案例的首選，例如預覽或客戶示範。

## 存取
<a name="access"></a>

根據最低權限原則指派許可。開發人員應該擁有與生產環境相同的預備環境存取權。

## 建置步驟
<a name="build-steps"></a>

無。在預備環境中重複使用測試環境中使用的相同成品。

## 部署步驟
<a name="deployment-steps"></a>

在測試環境中核准和部署之後，自動啟動預備環境中`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow) 的部署。以下是預備環境中的部署步驟：

1. 在預備環境中部署`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow)

1. 暫停以進行指定人員的手動核准

1. 下載已發佈的成品

1. 執行資料庫版本控制

1. 執行 IaC 部署

1. （選用） 執行整合測試

1. （選用） 執行負載測試

1. 從必要的開發、QA、產品或業務核准者取得核准

## 移至生產環境之前的期望
<a name="expectations-before-moving-to-the-production-environment"></a>
+ 生產同等版本已成功部署到預備環境
+ （選用） 整合和負載測試成功

# 生產環境
<a name="production-environment"></a>

*生產環境*支援發行的產品，由真實用戶端處理真實資料。這是透過最低權限指派存取權的受保護環境，且提升存取權只能在有限期間內透過稽核的例外狀況程序進行。

## 存取
<a name="access"></a>

在生產環境中，開發人員應該在 AWS 管理主控台中擁有有限的唯讀存取權。例如，開發人員應該能夠存取day-to-day操作的日誌資料。部署之前，應由核准步驟封鎖所有生產版本。

## 建置步驟
<a name="build-steps"></a>

無。在測試和預備環境中使用的相同成品會在生產環境中重複使用。

## 部署步驟
<a name="deployment-steps"></a>

在預備環境中核准和部署之後，在生產環境中自動啟動`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow) 的部署。以下是生產環境中的部署步驟：

1. 在生產環境中部署`release`分支 (Gitflow) 或`main`分支 (Trunk 或 GitHub Flow)

1. 暫停以進行指定人員的手動核准

1. 下載已發佈的成品

1. 執行資料庫版本控制

1. 執行 IaC 部署