Kanji
・雲端架構工程師 / 自由職業 ・1993年出生 ・愛媛縣出身 / 現居東京都澀谷區 ・5年 AWS 實戰經驗 個人檔案詳情
目錄
根據官方使用者指南，AWS CodePipeline 定義如下：
<塊引用> AWS CodePipeline 是一項持續交付服務，您可以使用它對釋出軟體所需的步驟進行建模、視覺化和自動化。 您可以快速建模和配置軟體釋出過程的不同階段。 CodePipeline 自動執行持續釋出軟體更改所需的步驟。
來源： 什麼是 AWS CodePipeline？- AWS CodePipeline
根據官方使用者指南，AWS CodeCommit 的定義如下：
<塊引用> AWS CodeCommit 是由 Amazon Web Services 託管的版本控制服務，您可以使用它來私密儲存和管理資產 （例如文件、原始碼和二進位制檔案）在雲中。
來源： 什麼是 AWS CodeCommit？- AWS CodeCommit
根據官方使用者指南，AWS CodeBuild的定義如下：
<塊引用> AWS CodeBuild 是一項完全託管的雲構建服務。 CodeBuild 編譯原始碼、執行單元測試並生成可供部署的工件。 CodeBuild 無需配置、管理和擴充套件您自己的構建伺服器。 它為流行的程式語言和構建工具（例如 Apache Maven、Gradle 等）提供預打包的構建環境。 您還可以在 CodeBuild 中自定義構建環境以使用您自己的構建工具。CodeBuild 可自動擴充套件以滿足峰值構建請求。
來源： 什麼是 AWS CodeBuild？- AWS CodeBuild
根據官方使用者指南，AWS CodeDeploy 的定義如下：
<塊引用> CodeDeploy 是一項部署服務，可自動將應用程式部署到 Amazon EC2 例項、本地例項、無伺服器 Lambda 函式或 Amazon ECS 服務。
您可以部署幾乎無限種類的應用程式內容，包括：
來源： 什麼是 CodeDeploy？- AWS CodeDeploy
根據官網，GitHub的定義如下：
<塊引用> GitHub 是一個受使用者想法啟發的開發平臺。透過在 GitHub 上託管原始碼， 從開源專案到商業使用，您可以與數百萬其他開發人員一起審查程式碼、管理專案並共同開發軟體。
來源： GitHub 日本 |GitHub
CI/CD 管道管理的資源候選包括應用程式原始碼、基礎設施即程式碼 (IaC) 以及構建和部署應用程式所需的配置檔案。使用這些資源部署的應用程式和基礎設施必須透過 CI/CD 管道作為程式碼進行管理，不僅在開發期間而且在運營期間。考慮CI/CD管道管理的資源是否可以作為程式碼進行管理，同時考慮到開發人員和運維人員的技能和操作。例如，考慮從 CI/CD 管道管理中排除以下情況：
CI/CD 管道管理的程式碼資源在 AWS CodeCommit 或 GitHub 等儲存庫服務中進行管理。AWS CodeCommit、AWS CodePipeline、AWS CodeBuild 和 AWS CodeDeploy 是 AWS 提供的服務，如果沒有現有的用於管理程式碼資源的儲存庫服務，AWS CodeCommit 將是第一個候選。但是，如下所示，AWS CodeCommit 將自 2024 年 7 月 25 日起停止接受新客戶。
<塊引用> 經過慎重考慮，我們決定自 2024 年 7 月 25 日起停止接受 AWS CodeCommit 新客戶。使用 AWS CodeCommit 的現有客戶可以繼續照常使用該服務。AWS 將繼續投資於 AWS CodeCommit 的安全性、可用性和效能，但沒有計劃推出新功能。
來源（日語翻譯）： 如何將您的 AWS CodeCommit 儲存庫遷移到另一個 Git 提供商 |AWS 開發運營和開發人員生產力部落格
目前尚不清楚 AWS CodeCommit 將來何時不可用，因此，如果您尚未使用 AWS CodeCommit，建議使用其他儲存庫服務來管理您的程式碼資源。與資料庫相比，遷移難度並不高，但一旦開始使用某個服務，遷移到另一個服務就很難了。考慮內部規則、可用功能、安全要求和未來前景，仔細選擇服務。
在某些情況下，使用 CI/CD 管道將相同的程式碼部署到多個環境或資源，例如：
為了解決這些問題，可以使用以下方法：
下面對每種方法進行解釋。
如果您採用 GitHub Flow 或 git-flow 等分支策略，則可以針對開發、登臺和生產等多種環境使用不同的分支。例如，您可以使用主分支進行生產，使用開發分支進行暫存，使用功能分支進行開發。在這種情況下，您可以執行由每個分支的更新觸發的 CI/CD 管道並部署到每個環境。由於開發人員可以自由命名和使用功能分支，因此需要 CI/CD 管道的動態執行。例如，AWS Prescriptive Guidance 引入了以下模式：
使用 AWS Service Catalog 和 AWS CodePipeline 自動化動態管道管理以將修補程式解決方案部署到 Gitflow 環境 - AWS Prescriptive Guidance
這樣做的好處是，透過檢查分支的內容，您可以輕鬆檢視哪些程式碼部署到了哪個環境。
缺點是隨著分支數量的增加，CI/CD管道的數量也隨之增加，管理變得更加複雜。此外，由於分支流程往往變得複雜，對於 Git 熟練程度較低的開發人員來說，分支管理可能會很困難。
此方法使用單個分支部署到多個環境或資源。例如，當主分支更新時，可以將相同的程式碼一次性部署到開發、暫存和生產環境中。
優點是減少了分支數量，使 CI/CD 管道管理更容易。
缺點是，由於相同的程式碼一次部署到所有環境，因此很難進行分階段部署，例如先部署到開發環境進行測試，然後再部署到分階段和生產環境。
建議在部署安全或監控服務等基礎設施資源（而不是應用程式資源）時使用此方法。
此方法使用手動作業來重用構建/部署工件並部署到多個環境或資源。例如，您可以重用部署到開發環境的應用程式的構建工件，並將它們部署到臨時或生產環境。在這種方法中，您可以在執行CI/CD管道後，透過手動執行作業來部署到所需的環境或資源。
優點是您可以透過重用構建/部署工件將相同的程式碼部署到多個環境或資源。此外，您只需要準備同時執行作業所需的 CI/CD 管道，因此可以減少 CI/CD 管道的數量。
缺點是在執行 CI/CD 管道並生成構建/部署工件後，您需要手動執行作業，這可能會增加分階段部署所需的工作量。
根據您構建 CI/CD 管道機制的程度，您可以構建高度通用的 CI/CD 管道。
CI/CD管道中用於管理資源的主要工具如下：
使用這些部署和構建/靜態分析工具，您可以對 CI/CD 管道管理的資源進行部署、構建和執行靜態分析。
注意：僅僅因為這些工具自動執行構建/部署過程並不意味著您不需要學習這些工具。 透過建立操作過程中更改引數檔案的流程，可以減少工具的學習成本，但在開發過程中，您將需要學習工具，因為您可能需要在自己的環境中構建/部署以進行故障排除，而不僅僅是透過 CI/CD 管道。選擇要在 CI/CD 管道中使用的工具，同時考慮開發人員的技能和操作要求。
一旦決定了工具，請考慮 CI/CD 管道的步驟。
如何考慮這些步驟正在準備中。
一旦決定了 CI/CD 管道中使用的工具，請確定這些工具管理的資源、其管理員和部署目標。例如，如果您使用 AWS CLI (CloudFormation) 部署 AWS 資源，請按如下方式組織：
組織時，重要的是要明確哪個團隊管理哪些資源以及這些資源的部署位置。對於每個託管資源，請在下一節“4. 儲存庫分段單元”中考慮由哪個儲存庫來管理它。
考慮如何將 CI/CD 管道管理的資源分段到程式碼儲存庫中。細分視角包括以下內容：
基本上，透過“1.功能”細分，還可以同時按“2.管理員”和“4.生命週期”細分。如有必要，請考慮在“1.功能”中進一步細分“4.生命週期”。例如，在對網路防火牆進行分段時，透過將資源分為初期建設部署和運營部署，可以避免防火牆本身被刪除的風險。在這裡，更詳細地組織“託管資源”。
對於“3.部署目的地”，考慮如何根據前面討論的“1.如何部署到多個環境/資源”的結果進行分段。例如，對於 GuardDuty，您可以按共享帳戶和每個環境帳戶進行細分，如下所示：
為每個分段程式碼儲存庫構建 CI/CD 管道時，請為每個 CI/CD 管道設定許可權。首先整理一下每個管理員哪些許可權是不能授予的，然後再考慮進一步限制許可權。例如，如果有三個團隊：平臺團隊、開發團隊、運營團隊，則可以按如下方式設定許可權：
重要的是不要將 CI/CD 管道許可權限制得太細。如果許可權限制過多，CI/CD 管道可能缺乏執行所需的許可權，從而導致部署失敗。此外，由於您可以使用拉取請求或批准階段來限制 CI/CD 管道本身的執行，因此不建議嚴格限制許可權作為針對內部欺詐的對策。如果您確實進行限制，建議使用以下 AWS 託管策略來授予必要的許可權。
AWS 託管策略 - AWS 託管策略