Share via

AX Source Control and Branching Guidelines

  • Article

The source control system supported by AX Developer ALM system is VSTS based TFVC (Team Foundation Version Control). If you are new to TFVC, please check - Develop and share your code in TFVC using Visual Studio

TFVC is a centralized version control system that storing source code in shared repositories, isolate parallel development efforts, integrate code changes, and to recover previous file versions.

Basic TFVC concepts

  • Branch: is an isolated copy of item metadata and version control history.
  • Changeset: is a logical container for changes of a single check in.
  • Label: provides mutable groupings of specific version of a set of source files.
  • Workspace: is a local copy of your codebase. You can create multiple workspaces and switch among them to work on different branches or copies of the codebase. A Workspace maps Server folders to Local folders. This includes:
    • A list of all the files in your workspace
    • The version of each file
    • A list of the pending changes
    • Active and cloaked items

Source Code Structure in TFVC for your AX application

In order to get started with TFVC version control for your AX project, you need to check in AX Modules you are developing under the Metadata folder. While provisioning the build environment if there is no custom branch name specified, a folder called Main is created for you while creating the build definition.

This is structure to follow to check in your code for X++ projects.

AxModules_Structure

You can consume .NET projects in your AX application and the default build definition created supports compiling and adding your .NET assemblies to AX Modules. In order to build and source control your C# projects please check them into TFVC following this structure.

DotNetProject_Structure

Common Branching Strategies for AX Development

Branching enables parallel development by providing each development activity a self-contained snapshot of needed sources, external dependencies and build orchestration automation. Having more branches increases complexity and merge costs. Nevertheless, there are several scenarios where you will need to consider multiple branches to maintain a required development velocity.

These are the branching strategies we recommend

  • No Branching: Do not branch unless you really need to. This is the simplest strategy to start with for your AX development project and works great for small teams developing a single version of the application at a time. Branching introduces cost of maintenance and shelveset is a great feature of TFVC to save and share changes in TFVC without committing them to the branch. For more information, please refer - Suspend your work and manage your shelvesets
  • Branch per release: Branch contains code for specific release version. This enables concurrent release management and isolation. It is recommended to branch everything you require to develop in parallel, typically this may mean branching the entire parent. Branch from a parent with the latest changes (usually MAIN or another DEV branch you specified in LCS)

branching

For steps to accomplish this please refer – Branch folder and files

We are in the process of evaluating distributed version control system - Git for AX development. Stay tuned for updates in this blog.

Comments

  • Anonymous
    May 30, 2016
    The current terminology for "module" is "package", right? Although it gets confused with deployable packages, it's probably better to talk about models and packages rather than models and modules (which looks and sounds similar).I also wonder why the recommendation uses both Trunk and Main. What's the advantage of having Trunk folder, instead of placing branches directly under project?