翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 5G ネットワークの CI/CD
<a name="cicd-in-5g-networks"></a>

インフラストラクチャの設計構造は、宣言言語を使用してコード形式で保存されます。これにより、CSP は、必要に応じて同じ期待される動作でインフラストラクチャを繰り返し再現できます。コードはコードリポジトリに保持され、パイプラインはデプロイされたスタック ( など) の更新を調整するように設定されています AWS CDK CloudFormation。 AWS は、独立系ソフトウェアベンダー (ISV) 関数のアジャイルオンボーディングのためのコードとしてのインフラストラクチャ (IaC) を構築するのに役立ちます。

![\[コードパイプラインフローを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g6.png)


*コードパイプラインフロー*

Helm チャートによるクラウドネイティブネットワーク関数設定の変更は、ネットワーク関数の自動 CI/CD パイプライン実行のトリガーと見なされます。

AWS CodeCommit を使用して設定ファイルを維持し、Amazon ECR を使用してコンテナイメージを保持できます。

*コードパイプラインのフロー*図に示すように、ISV が新しいコード変更をコードリポジトリ (Helm チャート、設定ファイル、またはプロパティファイル) にプッシュすると、コードパイプラインがトリガーされます。コードパイプラインは ECR からイメージをプルし、Helm チャートを使用してアプリケーションをデプロイします。新しいアプリケーションテストは、サードパーティーのテスト自動化フレームワークと統合できます。その結果に基づいて、CSPs本番デプロイを承認できます。

CodePipeline ソースステージは、設定ファイルの変更を検索します。ソースステージの有効なプロバイダーは、CodeCommit、Amazon S3、GitHub、または です CloudFormation。代替ソースシステムは、Lambda 関数を使用して Webhook を実装することで統合できます。これにより、Gitlab と 間のイベント駆動型統合が可能になります AWS CodePipeline。詳細な実装ガイドについては、以下のリンクを参照してください。
+ [GitLab を使用したウェブフック](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/ja_jp/whitepapers/latest/cicd_for_5g_networks_on_aws/images/cicd_5g7.png)


*アプリケーションの CI/CD パイプラインステップ*

各ステージは個別のタスクと見なすことができ、ネットワークサービスとクラウドネイティブなネットワーク機能をサポートするのに十分な検証とデプロイワークフローを組み込むことができます。実行タスクには、トラフィックジェネレーターやシミュレーターなどの追加のサードパーティーツールを組み込むことができ、end-to-endのネットワークサービス検証が可能になります。

AWS は、他の AWS サービスとネイティブに統合する高度な [AWS Step Function](https://aws.amazon.com/step-functions/) (クラウドネイティブステートマシン) サービスを提供し、Jira やテストオートメーションフレームワークなどの外部システムと統合することもできます。