Jun 29, 2011
Filed under: #daxmusings #bizapps

This is my first post containing an FAQ on the AX and TFS integration. I get a lot of the same questions, and below are the most commonly asked ones. This is a lengthy post so I apologize to the RSS subscribers.

Feel free to leave your questions in the comments, and I will keep this FAQ updated.

AX & TFS FAQ

Q: How to move one X++ project at a time, and what if it contains objects that have been modified for other X++ project as well?

A: This is where TFS' intelligent branching/merging process comes into play. The prerequisite is that you check in code for one X++ project at a time. That way, TFS knows which changes are "bundled" together. Obviously you can multiple changes over multiple days, but it is imperative that you never check in changes you made for different projects. When you merge a change set to another branch, which contains objects also modified by other projects that you are not moving, TFS will raise a flag. It will allow you to make a decision (on the XPO text) whether you wish to move the whole thing anyway, whether you want to move just the change associated with the change set you're moving, or whether you wish to manually modify the change to make it work. This works well for code in general but I always manually check to make sure anyway.

Q: How to build one project or one object or one changeset?

A: Although I understand the question in certain situations, I feel like there is never a good enough reason not to build the whole thing (except time perhaps). In any case, this basically boils down to creating a custom build workflow. When building just one object or one changeset, I'm fairly certain that can be done with the workflow. To build just one project, that is more tricky since TFS is not "aware" of projects, for what it's concerned, all it has is a text file (xpo) dubbed the "project definition". That being said, consider what we're doing with builds today: we are taking all XPOs and combining them into one giant XPO to import. What can be done of course it instead of combining all XPOs, first read a project definition, then combine only the objects described in that. Then follow the normal process for the build.

Q: How can we build a patch/hotfix layer?

A: This relates to the previous question. If you have a project containing the objects touched for your patch, you can use the combine-xpo approach I described above. If you want to build certain changesets only, either build a custom workflow, or consider perhaps a different branch, which can then be completely built in a patch layer…

Q: How can we have multiple developers work on the same AOS using TFS?

A: Due to the way the standard AX integration is designed, this is not possible. Of course in reality, this is a VERY common scenario, and Microsoft has asked a lot of questions and asked for lots of feedback from me and other in the community to try and solve this issue in AX2012. The solution unfortunately, has not worked it's way into the product. Instead, we will get more access to the integration code with TFS (the .NET "proxy" assembly is now a visual studio project in the AOT) so we can make any changes we need to ourselves.

A: That being said, in our AX2009 environments we do have multiple developers on one AOS. This is done through some customizations to AX, and some NTFS (windows filesystem) tricks. Bottom line: - We modify the AX integration to append the AX username to the local repository folder, this satisfies TFS that all users are using a different repository "working folder" - We add NTFS "junctions" so that although each user has its own folder, they are physically all the same folder (think sym links in unix/linux). This satisfies some issues with AX (namely if you have outdated XPOs there's a danger of updating the AOT with old code when you undo a chance for example).

Q: Can AX2009 support branching in the source tree? IE can I point AX 2009 to use a SUB-folder in my source tree rather than the root?

A: Standard AX 2009 will always put all the files starting at the root. Please note that this has been fixed in AX 2012 and you can specify a branch folder there.

A: For AX 2009, we have branching working at our offices at Streamline Systems. The only thing you really need to do is, after AX sets up your workspace, is changing that workspace (using visual studio) so that the working folder on the server points to your sub-folder. Of course, it only takes one user to not do this properly to mess up your source tree. To that end, we have automated this "fix" on the workspace by adding some .NET code in AX that gets executed when you log into AX, and changes your server working folder.

Q: In ISV scenarios, how can we maintain multiple components, and create unique builds for clients containing a unique combination of our components?

A: To be honest, I do not have a good answer to this. For big components, it makes sense to develop them in separate AX environments. For small ones, that sounds like overkill. In any case you can hook them up to the same ID server to avoid object ID collisions.

A: As far as branching is concerned, this would require a branch for each unique combination where you merge in the components you need. That is technically not unrealistic, but may be too much work for your scenario. Especially if you then need to branch for each release off of that…

A: I believe the AX developer community needs to start thinking more in lines of general software development practices, which in the past has never been the case. There are issues due to features and architectural challenges that are unique to AX, but most of the time those can be overcome. In this case, think of each component as a DLL or software product you would sell to a client. The uniqueness in AX is that they will all go in the same layer. But honestly, that's an installation detail, and it should not prevent you from considering each component as a unique product in your development cycle.

A: With the coming of AX 2012, the introduction of models, AxModel deployments and installations, I believe it will become easier to do these sorts of things.

Q: In client scenarios, clients may be doing their own development in a higher layer, how does that work?

A: When clients do development of their own, it should go in a higher layer than your delivered solution. This makes sense from a maintenance/support and liability point of view. We usually deliver our builds in a VAR layer and recommend customers use the CUS layer for their customizations.

A: In situations where you do off-site development and move layers into client environments (are current setup at Streamline Systems), it is true clients may be over-layering your objects so that any changes you make are not reflected in the final code layer "combination". To that end, you have a build log from TFS that can tell you what objects have been modified since the last release, and you have a layer compare in AX to detect layer conflicts. This sounds like a lot of work, but it isn't really. The point of source control is that you know exactly what has changed, so unless you have a ton of changes every release, the layer merge effort should be minimal.

A: In situations where there is development in multiple layers at the same time (such as traditional client projects where all development is done on-site), there are unique challenges. Even though for example fields on a table can be in different layers (ie not the whole table is in a layer at the time, like reports or forms in AX 2009), from a source control point of view the whole objects is moved into the higher layer. This prevents you from making ANY changes to the object in a lower layer as soon as it's over-layered. I have had numerous discussions with Microsoft on this subject, but there is no good way of resolving this.

Q: Why do we want to move layers and not XPOs as we’ve always done?

A: My favorite topic. Moving XPOs is literally moving source code (the XPO is a plain text file containing the source code). There are several issues with that approach: 1) the person importing the XPO can make mistakes (merge issues, object IDs, "delete tables and class members", etc). An XPO also implies someone took an export somewhere, which is the same issue, mistakes could have been made in the exporting. 2) from an auditing perspective this "should" be unacceptable: whomever imports this into production can modify the code, which is a segregation of duties issue, and a liability since after import the code cannot be guaranteed to be exactly the same as the test environment (export/import could introduce changes, merge issues, etc)

A: Usual complaints are one needs to take down the AOS to move in a new layer. My response to that is taking down the AOS, moving in the layer and starting it up again is a matter of minutes. Proper procedure when moving XPOs would be that all users are out of the system anyway, and that you do a full compile afterwards to make sure there are no issues. The difference is minimal, and not an excuse to keep doing XPO exports.

A: Moving compiled, binary code is the approach anyone should take. You do not receive hotfixes for Windows from Microsoft in source code form, you receive binary updates (new DLLs, EXEs, etc). This is also where Microsoft is going in AX 2012. There are models, and model exports (.AxModel). XPOs in AX 2012 are not the recommended way of moving code.

A: By moving code in layers, they can be versioned easily as "releases", which makes it easy to keep track of what version of the code is deployed where. XPO moves (unless extremely strictly controlled) have the potential of having different versions of different objects. Layers are the only guaranteed way of having two environments use the same code.

 

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