4.2 Branching, Merging & Conflict Resolution

4.2 Branching, Merging & Conflict Resolution

Quick Answer: Managing enterprise Dynamics 365 Finance and Operations (F&O) codebases requires a robust branching topology and disciplined merge procedures. A standard enterprise topology consists of Main (the stable, build-ready trunk), Dev/Feature branches (isolated branches where developers work on user stories), and Release/Servicing branches (frozen branches used for UAT stabilization and production emergency hotfixes). Code integration strictly follows two directional patterns: Forward Integration (FI), which merges code down from Main into Dev frequently to absorb peer changes, and Reverse Integration (RI), which merges code up from Dev into Main once feature work passes all quality gates. Because F&O elements are serialized as structured XML files, merge conflicts in table extensions (AxTableExtension), form extensions (AxFormExtension), and classes (AxClass) cannot be treated as plain text; developers must preserve valid XML tags, avoid duplicate element definitions, and safeguard <![CDATA[ ... ]]> code wrappers. Protected branches must enforce Pull Request (PR) policies with mandatory code reviews and automated Build Validation gates.

---

1. Enterprise Branching Topologies for Dynamics 365 F&O

In complex enterprise F&O implementations with multiple development streams, external ISVs, and continuous release cycles, a single-branch strategy is unsustainable. High-performing teams adopt a structured multi-tier branching topology in Azure DevOps.

Standard Three-Tier Branching Topology

1. Main Branch (The Trunk / Golden Source):
   • Serves as the central, authoritative source of truth for all validated custom code.
   • Always kept in a deployable, compilable state.
   • Developers never commit directly to Main; code enters Main exclusively via validated Pull Requests (PRs) or controlled merges.
2. Dev / Feature Branches (Child of Main):
   • Isolated branches where individual feature teams, sprint squads, or developers build customizations without destabilizing Main.
   • Short-lived or sprint-aligned. When a feature is complete and verified, it is merged back into Main.
3. Release / Servicing Branches (Child of Main):
   • Created at milestone cut-offs (e.g., Release/Sprint42 or Release/10.0.38).
   • Code in the Release branch is frozen for regression testing in Tier 2+ User Acceptance Testing (UAT) sandboxes.
   • If a defect is discovered during UAT or in Production, an emergency hotfix is developed and committed directly to the Release branch, tested, and deployed to Production. The fix is then integrated back into Main.

Branching Topologies Comparison

---

2. Integration Flows: Forward Integration (FI) vs. Reverse Integration (RI)

To prevent branches from drifting apart and creating insurmountable merge conflicts, teams must adhere to standard integration flows.

Forward Integration (FI): "Merge Down Often"

• Direction: From parent branch to child branch (e.g., Main $\rightarrow$ Dev/Feature1).
• Cadence: Performed frequently (daily or after every major merge into Main).
• Purpose: Pulls down code committed by other teams into the developer's isolated branch. Any conflicts between the developer's in-flight work and recently completed features are surfaced and resolved locally in the child branch, without risking the health of Main.

Reverse Integration (RI): "Merge Up When Stable"

• Direction: From child branch to parent branch (e.g., Dev/Feature1 $\rightarrow$ Main).
• Cadence: Performed once the feature is completely developed, unit tested, and code-reviewed.
• Prerequisite: Before initiating an RI merge, the developer must first perform a Forward Integration (FI) from Main into Dev, resolve any conflicts, and verify that the build succeeds locally. This guarantees that the subsequent RI merge into Main is conflict-free.

The Production Hotfix Flow

When a critical defect is identified in Production:

1. A developer creates a temporary hotfix branch from the active Release branch (or applies the fix directly in Release).
2. The hotfix is validated in a Tier 2 sandbox and deployed to Production via LCS.
3. The hotfix must immediately be reverse-integrated or forward-integrated back into Main (and subsequent active Dev branches). Forgetting to merge hotfixes back into Main causes the bug to resurface in the next major release (a regression defect).

---

3. AOT Element XML Serialization & Conflict Resolution

One of the most technically demanding tasks on the MB-500 exam is resolving merge conflicts in Dynamics 365 metadata. Unlike standard procedural code files where text diff algorithms reliably merge lines, F&O elements are defined by rigid, schema-bound XML.

How AOT Elements Are Serialized

Every AOT element is stored as a formatted XML document on disk:

• AxClass: An XML container wrapping class declaration attributes and method definitions. Each method's code is enclosed inside a <![CDATA[ ... ]]> block to prevent special characters (such as <, >, &&) from breaking XML parsing.
• AxTableExtension: An XML document containing arrays for <Fields>, <Indexes>, <Relations>, and property modifications extending a standard table.
• AxFormExtension: An XML document containing modifications to controls, datasources, and parts, specifying extension anchor points like <InsertAfter> or <InsertBefore>.

Anatomy of a Table Extension Conflict

Consider a scenario where Developer 1 and Developer 2 both extend CustTable in the same extension model (CustTable.ContosoExtension.xml):

• Developer 1 adds a new field: CreditLimitApprovalDate.
• Developer 2 adds a new field: TaxExemptCertificateNumber.

When both branches attempt to merge, standard 3-way text merge tools (which look for line differences) often misidentify the closing tags. A broken automatic merge may produce malformed XML such as:

<!-- CORRUPTED AUTOMATIC MERGE OUTPUT: DO NOT CHECK IN -->
<Fields>
  <AxTableField xmlns="" i:type="AxTableFieldDate">
    <Name>CreditLimitApprovalDate</Name>
    <ExtendedDataType>TransDate</ExtendedDataType>
  <!-- Missing closing AxTableField tag -->
  <AxTableField xmlns="" i:type="AxTableFieldString">
    <Name>TaxExemptCertificateNumber</Name>
    <ExtendedDataType>CertificateId</ExtendedDataType>
  </AxTableField>
  </AxTableField>
</Fields>

Rules for Resolving XML Metadata Conflicts

1. Maintain XML Validity: Every opening tag must have an exact matching closing tag with correct nesting. An unclosed <AxTableField> or duplicated </Fields> tag will cause the X++ compiler to fail with fatal XML schema validation errors.
2. Preserve Sibling Arrays: In extensions, new elements (such as fields, indexes, or field groups) must be structured as distinct, independent sibling elements within their parent collection tag (e.g., <Fields> ... </Fields>).
3. Handle Extension Control Anchors: In form extensions (AxFormExtension), extension controls specify insertion anchors (e.g., <InsertAfter>SalesTable_CustAccount</InsertAfter>). When two developers add controls to the same form group, ensure that both controls specify valid, non-conflicting anchor points and unique control names.
4. Safeguard CDATA Blocks in Classes: In AxClass files, ensure that merge conflict markers (<<<<<<<, =======, >>>>>>>) are completely removed and that the opening <Source><![CDATA[ and closing ]]></Source> delimiters are intact around every X++ method body.

Mandatory Post-Conflict Verification

Never commit a resolved merge conflict based solely on visual inspection in a diff tool. The developer must:

1. Save all resolved XML files in PackagesLocalDirectory.
2. Open Visual Studio and run a Full Build on the affected model.
3. Check the Error List for XML schema validation errors or duplicate element names.
4. Execute a Database Synchronization to verify that SQL schema generation succeeds without constraint collisions.

---

4. Pull Request (PR) Policies & Build Validation Gates

In enterprise DevOps governance, protected branches (Main and Release) must have Branch Policies configured in Azure DevOps to prevent untested or unreviewed code from entering production streams.

Azure DevOps Branch Policy Components

• Require a Minimum Number of Reviewers: Mandates that at least one or two designated senior developers/architects review and approve the PR. If new commits are pushed to the PR branch, approvals are automatically reset.
• Check for Linked Work Items: Prevents completion of the PR unless at least one active Azure Boards User Story, Bug, or Task is linked, ensuring audit compliance.
• Check for Comment Resolution: Enforces that all review discussions, architectural questions, and change requests posted by reviewers are explicitly marked as "Resolved".
• Build Validation (Automated Gate): Configures an automated Azure Pipeline that triggers whenever a PR is created or updated. The pipeline automatically checks out the merge commit, compiles all custom models, runs database synchronization, and executes automated SysTest unit tests. If compilation fails or any unit test breaks, the PR is blocked from completing.

---

5. Scenario Walk-Through: Production Hotfix & Reverse Integration

Scenario: Tax Calculation Hotfix During Active Sprint Development

Contoso is two weeks into Sprint 44. Developers are actively committing new features to Dev/Sprint44. Suddenly, a legal tax calculation defect is detected in the live Production environment (running code from Release/Sprint43).

Resolution Workflow:

1. Create Hotfix Branch: A developer branches Release/Sprint43 to Hotfix/TaxCalcBug.
2. Apply Fix & Test: The developer fixes the tax calculation class in Hotfix/TaxCalcBug, builds locally, and verifies the calculation.
3. PR into Release Branch: The developer creates a PR from Hotfix/TaxCalcBug into Release/Sprint43. The automated build validation passes, code review is approved, and the PR completes.
4. Production Deployment: The Release pipeline generates an SDP from Release/Sprint43, validates it in Tier 2 UAT, and applies it to Production via LCS.
5. Reverse Integration into Main (Crucial Step): To prevent Sprint 45 from undoing the hotfix, the developer merges Release/Sprint43 into Main via an approved PR.
6. Forward Integration into Active Dev: The sprint team performs a Forward Integration merge from Main into Dev/Sprint44, ensuring all active developers inherit the tax fix immediately.

---

6. Real-World Exam Traps: Branching & Merging

[!WARNING] Exam Trap 1: Merging Up (RI) Before Merging Down (FI) A common question describes a developer attempting to merge a feature branch directly into Main, only to encounter unexpected merge conflicts that corrupt the trunk build. The exam expects you to recognize that a developer must always execute Forward Integration (FI) from Main into Dev first, resolve conflicts and test locally, before performing Reverse Integration (RI) into Main.

[!WARNING] Exam Trap 2: Accepting Text-Based Automatic Merges on Metadata Files When Git or TFVC performs an automatic 3-way merge on an AxTableExtension XML file without conflicts, candidates often assume the merge is safe. On the MB-500, automatic text merges can generate syntactically valid XML that is semantically invalid (e.g., placing two controls at the same anchor point or duplicating array keys). Manual verification and a local Full Build are always required.

[!WARNING] Exam Trap 3: Direct Check-Ins to Main Any exam option proposing that developers check in emergency bug fixes directly to the Main or Release branch without a Pull Request or code review violates Microsoft ALM governance and is strictly incorrect.

[!WARNING] Exam Trap 4: Forgetting Hotfix Reverse Integration Questions frequently ask why a bug fixed in production hotfixes reappeared two months later after a major release. The root cause is that the hotfix was applied to the servicing branch and deployed to production, but the team failed to merge the fix back into the Main branch.