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

# 5G 網路中的 CI/CD
<a name="cicd-in-5g-networks"></a>

基礎設施的設計建構會使用宣告式語言以程式碼形式儲存。這可讓 CSP 對具有相同預期行為的基礎設施進行可重複的複製。程式碼會維護在程式碼儲存庫中，並設定管道來協調已部署堆疊的更新 （例如 AWS CDK 和 CloudFormation)。 AWS 可協助建置基礎設施即程式碼 (IaC)，以靈活加入獨立軟體廠商 (ISV) 函數。

![\[描述程式碼管道流程的圖表。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g6.png)


*程式碼管道流程*

透過 Helm Chart 的雲端原生網路函數組態變更會被視為網路函數自動 CI/CD 管道執行的觸發條件。

AWS CodeCommit 可用來維護組態檔案，而 Amazon ECR 可用來保留容器映像。

如*程式碼管道流程圖*所示，當 ISV 將新的程式碼變更推送到程式碼儲存庫 (Helm Chart、組態檔案或屬性檔案） 時，就會觸發程式碼管道。程式碼管道會從 ECR 提取映像，並使用 Helm Chart 部署應用程式。新的應用程式測試可以與第三方測試自動化架構整合。根據結果，CSPs 可以核准生產部署。

CodePipeline 來源階段會尋找組態檔案中的變更。來源階段的有效提供者為 CodeCommit、Amazon S3、GitHub 或 CloudFormation。使用 Lambda 函數實作 Webhooks 來整合替代來源系統，這可實現 Gitlab 和 之間的事件驅動整合 AWS CodePipeline。如需詳細的實作指南，請參閱下列連結。
+ [使用 GitLab 的 Webhook](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html)
+ [容器登錄整合](https://docs.gitlab.com/ee/administration/packages/container_registry.html)

CI/CD 管道設計應考慮重要的部署步驟，例如初始部署、測試，以及在測試結果符合預期並根據基準驗證之後提升生產環境。管道程序的每個階段都會提供資料成品，以便進行比較和資料驅動型決策。

![\[描述應用程式 CI/CD 管道步驟的圖表：變更、部署、測試、提升、監控。\]](http://docs.aws.amazon.com/zh_tw/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g7.png)


*應用程式 CI/CD 管道步驟*

每個階段都可以被視為單獨的任務，允許整合足以支援網路服務和雲端原生網路功能的驗證和部署工作流程。執行任務可以整合額外的第三方工具，例如流量產生器和模擬器，以啟用end-to-end網路服務驗證。

AWS 提供複雜的 [AWS Step Function](https://aws.amazon.com/step-functions/) （雲端原生狀態機器） 服務，可與其他 AWS 服務原生整合，也能夠與 Jira 或測試自動化架構等外部系統整合。