Oct 13, 2010
Filed under: #daxmusings #bizapps

I’m happy to report our TFS implementation is taking shape.<div>We our now actively using TFS for two implementations, and planning to add more projects soon, including clients we are supporting that are live already.</div><div> </div><div>Our current setup involves a TFS server, which also hosts the unfortunately named “Team Server” for Ax which manages the object IDs.</div><div>We have a Hyper-V hosted virtual server 2008 for each client project, where only developers have access. This virtual server hosts the Ax development environment hooked into TFS.</div><div>When development is ready to be tested by our consultants, one of the developers is responsible for merging the code into the TEST branch. This is done based on changesets, the policy is the changeset check-in comments need to clearly identify the development task number. Based on the changeset comments’ task numbers, the developer (we’ve dubbed him the “branch manager”) merges changesets into the TEST branch (at which point the TFS development work items are associated… a great tool for reporting what went into a new release!). TFS detects any code conflicts, which can fairly easily be resolved using the TFS compare tool (on the XPOs).</div><div>When all is merged, we have a TFS build that will be queued, which automatically refreshes our AOS server (combines all XPOs into one, shuts down the AOS, moves the layers into “old”, copies the most recent label files from the source control tree into the application directory, deletes label and layer indexes, starts the AOS, imports the code + compile, runs a synchronize). The whole build process takes about 30-40 minutes. When all is done, it actually stops the AOS again, copies the layers out and TFS puts those in the drop folder together with the label files (and starts the AOS again).</div><div>When things are properly tested and ready for client/user testing, we merge those changesets into the RELEASE branch, which will then also again build a release AOS, more for the purpose of getting a layer file built (and for one client test the final product before shipping to client, to make sure there’s no branch/merge issues).</div><div>Our drop folder now contains labels and layer to be shipped to the client.</div><div> </div><div>Important to note our script to combine XPOs will add a macro in the XPO that contains the build number from TFS. This is necessary to easily identify the build number a client has running on their different environments.</div><div> </div><div>That said (and noting we’re pretty excited about our new process which has been great so far), several obstacles had to be overcome to get here.</div><div>Besides my explanation in the previous post about using TFS 2010, there are SEVERE limitations to the setup. On a given machine, only one user can use a particular local repository folder or TFS complains (as I understand it, it’s more a Ax limitation of using TFS options such as public workspaces) about the workspace already being in use.</div><div>A workaround would be to use a separate folder for each user. Well, there’s two Ax issues with that. First, Ax expects to find the XPO for a source controlled object in your local repository. So if someone added an object in the Ax AOT, you will see it in the AOT, but your local repository will probably not have the XPO. Annoying Ax-AOT errors ensue.</div><div>Secondly, there is just no way to specify different folders for different users in the Ax source control setup.</div><div> </div><div>The solution we came up with consists of (1) a customization to the Ax - TFS integration to support different folders for different users, and (2) make those user folders NTFS junctions to the same folder, so all XPOs will always exist.</div>

 

There is no comment section here, but I would love to hear your thoughts! Get in touch!