AZ-400 Question 62
Single answerYou are leading a DevOps team developing a microservices-based application in Azure DevOps. The main branch must remain stable and always be ready for production deployment. Feature development should happen in isolation, and you want to enforce code reviews before merging changes into the main branch. Which branching strategy should you adopt to meet these requirements?
- A
Use trunk-based development with short-lived feature branches, requiring pull requests to merge into main.
- B
Maintain a single main branch and commit all feature changes directly into it without separate feature branches.
- C
Adopt GitFlow with a dedicated develop branch, merging feature branches into develop before eventually merging into main.
- D
Create a long-lived branch for each feature and merge them into main only after a release branch is created.
Show answer and explanation
Correct answer: A
Explanation
For quick development while ensuring stability, trunk-based development with short-lived feature branches is a leading practice as recommended in Microsoft� DevOps documentation. It keeps the integration process streamlined, enables continuous code reviews, and ensures main remains production-ready at all times. You can learn more about recommended branching strategies in the official Azure DevOps documentation under 'Adopt a Git branching strategy.'
- A. Correct.
Correct. Trunk-based development with short-lived feature branches is well-suited for keeping the main branch stable. Each feature branch is created off main and requires a pull request (PR) with code review and CI checks before merging back to main. This minimizes merging complexity and ensures that main remains production-ready.
- B. Incorrect.
Incorrect. Committing directly to the main branch without separate feature branches makes it harder to isolate new work. It also risks introducing unstable code into the main branch, especially if code reviews or automated tests fail.
- C. Incorrect.
Incorrect. While GitFlow can be a valid approach, it introduces a develop branch, which adds extra merging steps before changes reach main. This may be acceptable in some scenarios, but it's more complex than necessary if the primary requirement is a stable main ready for production and quick PR-based integrations.
- D. Incorrect.
Incorrect. Long-lived branches can lead to merge conflicts and complicate continuous integration. Keeping feature branches around for extended periods increases the risk of divergence from the main branch and slows down the feedback cycle.