Development-Lifecycle-and-Deployment-Architect-JPN日本語参考質問79：Universal Containers は、大規模なカスタム開発を伴う Salesforce 実装の次の開発フェーズに取り組んでいます。開発の途中で発生する重大な運用上の問題に対処するには、次の 2

<<前へ次へ>>

質問 79/103

Universal Containers は、大規模なカスタム開発を伴う Salesforce 実装の次の開発フェーズに取り組んでいます。開発の途中で発生する重大な運用上の問題に対処するには、次の 2 つの戦略を検討する必要がありますか? 2 つの答えを選択してください

A. 現在の開発と本番環境のバグ修正用に個別のブランチを作成し、準備ができたら現在の開発に修正をデプロイします。 B. 開発と運用の両方のバグ修正に 1 つのブランチを使用して、非同期ブランチを回避し、デプロイを簡素化します。 C. ソース管理システムを利用して、現在の開発と本番環境のバグ修正を別々のブランチにできるようにします。 D. コードが修正されたら、問題を再現し、ユースケースシナリオをテストするためにサンドボックスを更新します。

最新のコメント (最新のコメントはトップにあります。)

jg - 2026-01-09

この問題は、進行中のプロジェクト（次期開発）と、本番環境で発生した緊急の不具合対応（Hotfix）を、ソース管理システム（VCS）を用いていかに安全に並行管理するかを問うています。
正解：A, C
解説
大規模なカスタム開発を行っている最中に本番障害が発生した場合、開発中の未完成なコードを本番へ混ぜるわけにはいきません。そのため、**「コードの分離（分離されたブランチ）」**が不可欠です。
なぜ A と C が最適なのか？
* A: 個別のブランチ管理: 本番環境のバグ修正用に専用のブランチ（Hotfixブランチ）を作成します。これにより、開発中の新機能（Featureブランチ）の影響を受けずに、修正だけを本番へデプロイできます。修正完了後は、その内容を「現在の開発（Develop/Feature）」にも取り込む（マージする）ことで、次回のリリース時にバグが再発するのを防ぎます。
* C: ソース管理システムの活用: このような複雑な並行作業を実現するには、Gitなどのソース管理システムが必須です。Gitを利用することで、異なる目的のコードを別々のブランチとして並行して保持し、必要に応じて統合（マージ）することが可能になります。
他の選択肢が不適切な理由
* B. 1つのブランチを使用する: 開発中のコードとバグ修正を同じブランチで管理すると、本番デプロイ時に「まだ完成していない新機能」まで一緒にデプロイされてしまい、さらなる障害や予期せぬ動作を引き起こすため、極めて危険です。
* D. サンドボックスを更新（リフレッシュ）する: 運用上の問題が発生した際に、検証のためにサンドボックスを更新すること自体は一般的ですが、リフレッシュには時間がかかる場合があります。また、この選択肢は「バグ修正の戦略（並行開発の管理方法）」としては不十分であり、ソースコードの整合性を保つ解決策にはなっていません。
アーキテクトの視点：Hotfix のワークフロー
実際の現場では、以下のようなステップ（Hotfix ワークフロー）を推奨します。
* Main/Masterブランチ（本番と同じ状態）から Hotfixブランチを作成。
* 開発者が Hotfixブランチで修正し、Sandboxでテスト。
* 修正された Hotfixブランチを Main へデプロイ。
* 重要：修正した Hotfixブランチの内容を Develop（開発中）ブランチにもマージする。
次は、この「修正を開発ブランチに戻す（マージする）」際、コンフリクト（競合）が発生した場合の対処法...

質問 79/103

最新のコメント (最新のコメントはトップにあります。)

コメントを発表する

Download PDF File