翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CI/CD について
継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。場合によっては、CI/CD の D はデプロイを意味することもあります。継続的デリバリーと継続的デプロイの違いは、本番環境に変更をリリースする際に発生します。継続的デリバリーでは、変更を本番環境に昇格させる前に、手動による承認が必要です。継続的なデプロイは、パイプライン全体を通じて中断のないフローを特徴としており、明示的な承認は必要ありません。この戦略では一般的な CI/CD の概念について説明するため、提供される推奨事項および情報は、継続的デリバリーと継続的デプロイメントの両方のアプローチに適用できます。
CI/CD は、コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインは、ソース、ビルド、テスト、ステージング、および本番環境の各ステージを包含します。各ステージにおいて、CI/CD パイプラインは、コードをデプロイまたはテストするために必要なすべてのインフラストラクチャをプロビジョニングします。CI/CD パイプラインを使用すると、開発チームはコードに変更を加えるだけで、その変更が自動的にテストおよびデプロイにプッシュされるようになります。
完全な CI/CD である状態から、意図的であるか無意識であるかにかかわらず、逸脱する可能性のあるいくつかの方法について説明する前に、基本的な CI/CD プロセスを確認しましょう。次の図は、CI/CD のステージと、各ステージにおけるアクティビティを示しています。
継続的インテグレーションについて
継続的インテグレーションは、GitHub の Git リポジトリなどのコードリポジトリで行われます。単一のメインブランチをコードベースの信頼できるソースとして扱い、機能開発用に短期間のブランチを作成します。機能を上位環境にデプロイする準備ができたら、機能ブランチをメインブランチに統合します。機能ブランチは、上位環境に直接デプロイされることは決してありません。詳細については、このガイドの「トランクベースのアプローチ」を参照してください。
継続的インテグレーションプロセス
-
開発者はメインブランチから新しいブランチを作成します。
-
開発者は変更を行い、ビルドとテストをローカルで行います。
-
変更の準備が整ったら、開発者はメインブランチを送信先としてプルリクエスト
(GitHub ドキュメント) を作成します。 -
コードがレビューされます。
-
コードが承認されると、そのコードはメインブランチにマージされます。
継続的デリバリーについて
継続的デリバリーは、開発環境や本番環境などの分離された環境で行われます。各環境で発生するアクションは状況によって異なる場合があります。多くの場合、最初のステージの 1 つは、先に進む前にパイプライン自体を更新するために使用されます。デプロイの最終的な結果は、各環境が最新の変更で更新されることです。ビルドおよびテスト用の開発環境の数も状況によって異なりますが、少なくとも 2 つを使用することを推奨します。パイプラインでは、各環境はその重要度の順に更新され、最後に本番環境 (最も重要な環境) が更新されます。
継続的デリバリープロセス
パイプラインの継続的デリバリーの部分は、ソースリポジトリのメインブランチからコードをプルし、それをビルドステージに渡すことによって開始されます。リポジトリの Infrastructure as Code (IaC) ドキュメントでは、各ステージで実行されるタスクを概説しています。IaC ドキュメントの使用は必須ではありませんが、IaC サービスまたはツール (AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) など) の使用は強く推奨されます。最も一般的なステップには、次のものがあります。
-
ユニットのテスト
-
コードのビルド
-
リソースのプロビジョニング
-
統合テスト
パイプラインのいずれのステージでも、何らかのエラーが発生するかテストが失敗した場合は、現在のステージは以前の状態にロールバックされ、パイプラインは終了されます。後続の変更は、コードリポジトリで開始し、完全な CI/CD プロセスを経由する必要があります。