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

# よくある質問
<a name="faq"></a>

## デプロイプロセスが完全な CI/CD ではないことを示す主要な指標にはどのようなものがありますか?
<a name="faq-key-indicators"></a>

最も一般的な指標は、パイプライン内で個別の環境を表す複数のリポジトリブランチが存在する場合です。完全な CI/CD プロセスのリポジトリでは、トランクベースのワークフローが使用されます。このワークフローでは、1 つのブランチがそのリポジトリのデプロイに対する唯一の信頼できるソースとして機能します。詳細については、「[トランクベースのアプローチ](fully-cicd-process-differences.md#trunk-based-approach)」を参照してください。その他の指標には、単純な実行可否の判断以外の手動デプロイ手順、ホットフィックスの使用、スケジュールされたリリースなどがあります。

## 完全な CI/CD プロセスを使用したいが、特定の機能のリリースを特定の時点にスケジュールしたい場合はどうすればよいですか?
<a name="faq-scheduled-releases"></a>

これは通常、機能フラグを使用して行われます。このプロセスでもデプロイは継続的に行われますが、特定の機能はリリースのタイミングがくるまで、コード内の条件付きクロージャを使用して非表示にされます。

## デプロイプロセスの一部の手順を自動化できない場合はどうなりますか?
<a name="faq-automated-steps"></a>

完全な CI/CD パイプラインの目標の 1 つは、手動プロセスの必要性を最小限に抑えることですが、手動プロセスが必要となる可能性のあるユースケースが存在することも確かです。実際、読み取り専用プロセス (アプリケーションログの参照など) は、多くの場合、本番環境でも最小限のリスクで実行できます。しかし、本番環境での手動による書き込みアクションは、絶対的な最終手段として扱うことが強く推奨されます。

## 技術スタッフが、完全な CI/CD プロセスよりもレガシーワークフローに慣れている場合はどうすればよいですか?
<a name="faq-resistance-to-change"></a>

技術スタッフが大きな変更に抵抗を示すことはよくあります。特に、以前はベストプラクティスであったものが新しいものに置き換えられる場合はなおさらです。テクノロジーは急速に進歩し、改善が絶えず発見されています。技術スタッフにとって一定の懐疑心を持つことは良い資質ですが、変化を受け入れることも同様に重要です。懐疑的なスタッフに対しては急ぎ過ぎないようにしてください。彼らは、システムに対する変更を実装前に管理する必要があるためです。重要なのは、懐疑的なスタッフが永遠に停滞することを防ぐことです。

## 複数のアカウントに環境が存在する場合はどうすればよいですか? その場合も完全な CI/CD プロセスを使用できますか?
<a name="faq-multiple-accounts"></a>

はい。実際には、環境ごとに個別のアカウントを使用することが推奨されます。異なるアカウントのステージをアクティブ化するパイプラインの詳細については、「[別の AWS アカウントのリソースを使用するパイプラインを CodePipeline で作成する](https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html)」を参照してください。