2

We use TFS for our version control system in AX 2012, and have been experimenting with branching for the purpose of better controlling what goes into testing and release environments.

Microsoft gives the example scenario here of a main branch, then two child branches Dev/Release.

How do you actually do this in AX? Merging in Visual Studio with XPO exports isn't the same as merging traditional source files.

Do you configure TFS parameters inside of AX to point to a Dev branch, then check-in code? Then at some point change the TFS parameters to the Release branch and re-check-in code?

What's the practical use of it?

Alex Kwitny
  • 11,211
  • 2
  • 49
  • 71
  • [How We Manage Development - Organizing TFS](https://community.dynamics.com/ax/b/daxmusings/archive/2013/02/28/how-we-manage-development-organizing-tfs) may be an alternative way to do it. – FH-Inway Sep 11 '15 at 08:38

2 Answers2

2

We are using TFS integration with AX 2012 this classical way, with Main, Dev and Release branches.

TFS integration is setup in AX. Then merge at check-in if there was concurrent modifications is done by TFS. If needed, TFS merge popup if it Can't resolve the conflit itself. The merge between branches is dons in TFS too.

You must not change on the Fly the branch your are setup on. One major thing in AX TFS integration is to keep consistency between AX modelstore and local repository. When you will check an object out or get its latest version, it won't compare the TFS server version with the current in AX but in the local repository. If you need to reaffect one dev environment to another branch, you'll have to set the modelstore and the repository local at the same level on the targeted branch and change the setup in AX.

The main purpose is to have in Dev branch all the on going developments and run nightbuilds to validate technically the current version. The Main branch is the one you will merge into validated developments to create release candidates to pus to tests and UATs. The Release branch is to have the exact version of your Live environment in order to make hotfixes without the ongoing evolution in Dev and Main branches.

Geoffrey DELMEE
  • 772
  • 4
  • 8
  • Let me see if I have this right. So you leave AX-TFS setup to the Dev branches and do check-ins that way. Then inside of visual studio, merge dev to main when a development is validated. Then when you want to make a release, you create a new release branch? And validate that release branch? – Alex Kwitny Sep 14 '15 at 16:17
  • That's the way I do but the Release branch. I change the model number in Model.xml in order to move forward the number of the release candidate and set labels on each version. I create the Release branch only at go live to have the same version in this branch as the version in Production environment. Then I can do hotfixes on this branch, totally isolated to current evolutions in Dev branch or already merged in Main branch to have a new release cadidate to be tested in UATs. – Geoffrey DELMEE Sep 15 '15 at 15:28
0

We use an isolated branch per developer and a MAIN branch where we all merge to. And then extra branches for TEST and PROD for code promotion of changes.

MAIN branch has a build process that compiles it recurrently so we are sure the merged changes are still solid, and TEST branch has a build process that deploys to a test AOS for consultants. PROD branch is only for historic reasons, no build or AOS is related with this code.

j.a.estevan
  • 3,057
  • 18
  • 32
  • So in AX, each Dev has a different branch folder setup in their TFS parameters? Then they check-in code in AX, and manually merge check-ins to MAIN in visual studio? – Alex Kwitny Oct 28 '15 at 16:35
  • That's it. Each developer works in his own isolated virtual machine too. – j.a.estevan Oct 28 '15 at 16:59
  • How often do developers sync changes from the Main branch though? For the TEST branch build process, do you just fully deploy Main somewhere? – Alex Kwitny Oct 28 '15 at 17:13
  • MAIN is not deployed, only compiled. TEST build processes test branch, that only have finished, reviewed merged changes. DEVs refreshes from main when needed, usually before every merge to main to avoid conflicts. – j.a.estevan Oct 29 '15 at 08:51