AZ-400 D3 ビルド・リリースパイプラインの設計と実装
268 問
AZ-400 D4 セキュリティとコンプライアンス計画の策定
72 問
AZ-400 D1 プロセスとコミュニケーションの設計と実装
48 問
AZ-400 D2 ソース管理戦略の設計と実装
47 問
AZ-400 D5 インストルメンテーション戦略の実装
40 問
AZ-400 D3 ビルド・リリースパイラインの設計と実装
20 問
問1. 8人の開発チームが週数回リリースしている。現在は機能ごとのブランチを2〜3週間保持し、レビューはまとめて依頼しているため、レビュー待ちとマージ時の競合が増えている。変更の追跡容易性を保ちながら、待ち時間と競合を減らす方針として最も適切なのはどれか。
- 機能を小さな変更単位に分割し、短命な作業ブランチから早期にPull Requestを作成して頻繁に統合する。レビュー対象と差分を小さく保ち、各変更を個別に追跡する
- 機能単位の長期ブランチを維持し、実装完了後にまとめてPull Requestを作成する。レビュー回数を減らして作業を中断しにくくし、統合時に一括で確認する
- チームごとに長期の共有開発ブランチを設け、各メンバーの変更をそこへ集約する。レビューを共有ブランチへの統合後に行い、mainへの反映時に履歴を整理する
- 作業ブランチを長く保持したまま、Pull Request作成直前にmainの最新内容を取り込む。統合時の競合を抑えつつ、レビューは完成した差分を一度に実施する
問2. 複数チームが同じmainを共有するサービスで、通常は小さな変更を日に何度も統合し、障害修正は数十分以内に本番へ届ける必要がある。すべての変更について統合前に変更理由と最低限のレビューを残し、承認記録を履歴から追跡できることも求められている。フィードバックの質、緊急時の速度、作業履歴の一貫性を同時に満たす運用はどれか。
- 通常変更も障害修正もmainへ直接統合し、統合後にPull Requestを作成して変更理由と指摘を記録することで、待ち時間を抑えながら履歴を残す
- すべての変更をPull Request経由にし、通常変更と障害修正で同じ完全な回帰テストと同じ承認手順を適用して、手順の統一を最優先する
- 通常変更は短命ブランチのPull Requestで通常レビューと検証を行う。緊急修正は短命ブランチの簡略化したPull Requestで影響範囲に絞った必須チェックと指定された承認者の承認を通し、復旧後に追加のレビューと記録を補完する
- 長期の統合ブランチへ各チームが直接変更を集約し、リリース候補をまとめてPull Requestでレビューして、緊急修正だけはmainへ直接反映する
問3. 8人の開発チームがmainへ日に十数回マージし、Pull Requestのレビューには平均1〜2日かかる。レビュアーにはレビュー中の差分をできるだけ安定させたい一方、マージ直前には最新のmainと先行する変更を含めた状態で必須テストに合格していることを保証したい。mainが更新されるたびに作業ブランチを更新してレビューやCIをやり直す運用は避けたい。この条件に最も適した設計はどれか。
- mainが更新されるたびに全Pull Requestの作業ブランチへ自動マージし、毎回レビュー承認を取り直して必須テストを再実行する
- Pull Request作成後は作業ブランチを一切更新せず、レビュー時点のテスト結果だけを使ってmainへ順次マージする
- Pull Requestでは通常のレビューと必須チェックを行い、mainではマージキューを必須にする。キュー内で最新のmainと先行変更を組み合わせた一時的な統合結果に対して必須チェックを実行し、成功した変更だけを順次マージする
- mainへのマージを一日一回に制限し、その直前に全Pull Requestを同時に最新化して、全件のレビューとテストを最初からやり直す