Why You Should Be Using Team Foundation Server for Dynamics AX Lifecycle Management? [ENG]
If you already use Team Foundation Server in your Dynamics AX projects, providing all benefits it can give to your teams, or if you are already convinced to use it soon, then this article is not for you.
You may not be convinced or, even worst, you may disagree about it to be beneficial to your methodologies and team behaviors. You can try to challenge my points with your project’s circumstances that make TFS unacceptable. That’s fine. I’m only asking you to read the full article first!
Team Foundation Server (or Visual Studio Team Services*) is a tool, and as such, it will allow you to achieve the same tasks faster and with less effort. Furthermore, TFS will also give the ability to execute crucial tasks that are only available by using this kind of tools. Those tasks are mostly related to development work and source code management, what makes developer’s life easier, but some of them also help project managers and consultants, and support Quality Assurance guidance and validations, testing and all the rest of Application Lifecycle Management steps, whichever methodology is used to manage our projects: Microsoft SureStep, Agile, Scrum, …
Not to mention that using TFS is mandatory in the new Dynamics 365 for Operations, so including it in our lifecycle processes today will ease the transition and will put in place a set of Best Practices than will improve your team since day one.
Let’s have a look at the benefits of TFS in the three main categories of Application Lifecycle Management:
1. WORK
WORK module is meant to support project management tasks, but we can get much more from it if we make it part of our team toolbox.
It is a simple, generic, but effective Work Item manager that can be used effectively depending on the methodology used to manage each project. By default, the system creates Work Item Types like Epic, User Story, Task, Test Case, Bug, and so on, but what is more important is that these items are here to support our needs, so use them accordingly.
It is not mandatory to manage tasks and requirements but it will help you improve Project Management traceability across the team (you can even create those items from Microsoft Project Server). It allows linking code and metadata changes done by one developer, with a comprehensive description that anyone can understand. Thus, at any time everybody will know why a change was done and can provide information about testing and deployment status of every single request received from users, customers or whoever our stakeholders are.
Here are a few examples of critical questions that can only be answered when Work Items are used:
- Who made this change? Was something else changed at the same time?
- Why was this object modified? Is this change related to any business requirement, a bug fix, a compliance change request?
- When was this object modified the last time?
- How many times has this object been modified? What were the motivations for each change?
- Which was the application version at the time this change or bug fix was introduced? (Hotfix servicing and upgrades will be a blog post by itself)
- Which are the differences between the current status of the application and the one when this change was made?
- Estimate hotfix potential conflicts or code upgrades based on the changes you can see in source control.
This is a small set of questions you can answer with the most basic use of source control integration with Work Items. The list grows when you start using Branches and a proper build practice as we will see in upcoming blog posts.
Furthermore, you can map your BPM processes from Lifecycle Services with TFS Work Items to synchronize elements between and make easier to the team to access their information using their preferred tool.
2. CODE
This is the TFS module used by developers during code and metadata (AOT changes) changes, and where “versions” of the application are stored.
Source Control system provided by TFS makes developer’s life easier and safer and therefore, more profitable for their companies. It is unlikely to see a developer actively refusing to use any source control system. Those advantages are significantly more important when talking about development teams, and amazingly better when talking about distributed teams working in different locations, different countries, different companies (partners) or even different time zones. The more complex the team, the more benefits they will get from any source control mechanism in place.
You may argue that TFS causes extra work to developers. And that is true in theory, but let’s explain how this “extra” work is quickly amortized. Extra steps for developers using a source control system
- Check-Out: Before modifying an object, the developer needs to indicate the system that this objects is going to be modified. The system will download the last version from the server, just in case any other developer has modified it, so we can work with the latest version.
- Check-In: After changes are done and validated by a developer, a check-in will send those changes to the server so other developers can see our modified version, and will release the previous Check-Out made to this object.
- Merge: As many developers may be working with different versions of the same object on their isolated development environments at the same time, making changes to the same piece of code without knowing each other work-in-progress, the final version of the object may need to be manually merged. During merge process, a developer push his version into the server and will needs to take decisions about the final, consolidated version of the object if there are conflicts. Those conflicts can happen if somebody else has made changes to the server version since the current developer downloaded the last version during the Check-Out. All source control systems have tools to make the merging process easy and secure, even automatic if the changes are simple enough.
It doesn’t seem like a lot of extra work. Now let’s analyze what we get in exchange and it will get even better:
- Check-In/Check-Out mechanism allows several developers to work on the same object without disturbing each other. While modifying an object, a developer needs to save and execute it many times until the final version is ready. It won’t be until the developer checks-in this finished version than the rest of developers will even see those changes. When a developer synchronizes changes from a colleague, it will always get a complete change set, so he won’t be disturbed with unexpected errors due to unfinished changes, something common in shared development environments.
- Merging changes can be annoying in some cases. But following a good methodology will always be easier than importing XPO files, as the Visual Studio merging tool is way more sophisticated, powerful and quick than the MorphX Compare Tool (it’s fair to say that performance has been really improved in last versions). Anyway, the result of this merging process will always be saved to the server as a new change set. If something goes wrong, one can always see exactly what has been merged, fix it, or rollback to a previous version. Neither of this is available when we are asked to import an XPO file. After we import the file we can’t undo any change or even know what was the previous state.
- Every Check-In is saved to the server as a change set. This change set links all changes done at the same time to code and metadata to multiple objects, and can be linked to a Work Item or more than one as we mentioned earlier. With minimum effort (like providing a Work Item code during the check-in process, see the previous screenshot), we are creating a fully descriptive change set containing new, modified and deleted objects, and the Task/Bug/Requirement that motivated those changes. This will provide full traceability for every change made and can be even better if we follow some easy rules to merge between Branches allowing, for example, to make code reviews using those Branching change sets.
- Saving all change sets to the server allows everybody in the project to inspect the change history of any single object in the application, comparing different versions to see what has been the changed over time and, if linked to Work Items, who and why was it changed.
As an example, in the image below we have a full change set as shown by the VSTS portal (it can be accessed from Visual Studio too), showing new and modified objects, the link with 2 work items, and detailed code and metadata changes highlighted in different colors:
As this view is pure TFS tooling, any member of the team, regardless of knowledge or access to a Dynamics AX instance (of course TFS have its own access and security system), will be able to see and review this change history forever, as this is stored in the source control server regardless of what happens with the Dynamics AX test or development instances. A Dynamics AX 2012 development system based on any version stored in TFS server (including any Branch) can be deployed at any time, as we will see when talking about the BUILD & RELEASE module.
Same example as seen above, but this time from a Dynamics AX 2012 development environment perspective is shown below:
This is an invaluable tool for developers to be able to quickly see the change history of any object and navigate to this version in the AOT, compare with the current or any other version of the object and see what has been changed, or even reverse the current status to a previous version to undo any involuntary or mistaken change. Any developer will love that, there is not much discussion here.
All this code traceability is only possible when TFS is used to track changes. Dynamics AX is such a business-critical application that any code change should be described, controlled and traced. Who, when and why any change is done needs to be clear and easy to access. Customers without such traceability put themselves in dangerous path for regression problems and code instability.
We are still not considering the concept of Branching, closely related with any source control system, which roughly represents different versions of the entire application that we can manage independently. It allows to maintain a detailed version history (What was the status of my application at a specific point of time) that goes in line, but way more in deep of Dev/Test/UAT typical granularity. Branching is an interesting but extensive topic, so we will dedicate a full blog post in the future if our readers are interested on the subject.
3. BUILD AND RELEASE
I must admit, build module is my favorite topic: it is where development lifecycle gets closed and the benefits of using a full Application Lifecycle Management (ALM) process can be appreciated in a clear and obvious way by all the team. But it is quite a big topic too, so I will let the details for an upcoming post.
To sum up: In Dynamics AX 2012, we can work with a source control system to develop code and metadata changes, and then export them as a model (I don’t consider XPO files a valid promotion artifact). That works out of the box, but we can go a step further and put in place some automatic tooling to make our deployments quicker, easier and more predictable. The more predictable is a process, the easier to automate it. The more automatic, the stronger and error proof.
Imagine all changes done by our distributed development team are compiled, packed and deployed every night to a consolidated test AOS, so every change finished by our developers the previous day is available to the Testers every morning: That’s the kind of automation we can do with the BUILD AND RELEASE capability.
There is plenty to talk about BUILD AND RELEASE automation and its possibilities, but this post is getting longer than expected. Let’s follow up on the next ones.
If you still want to prove me wrong about TFS usage, I will be happy to discuss individual cases with you. I worked myself as a developer and development team lead using TFS, so I am very aware of some limitations regarding physical infrastructure needed for isolated environments, for instance. But, please, always consider that actively avoiding the use of a Version Control System on software projects (and a Dynamics AX implementation is such a project) has a prize that somebody will need to pay for.
Give it a try**. Start simple and evolve as you discover potential improvements to your ALM cycle. Analyze pros and cons, always trying to get the most of the tools.
* I use TFS acronym regardless of the version we are talking about, either on premise (called Team Foundation Server) or cloud (called Visual Studio Team Services, or VSTS) as they are pretty much equivalent with minor differences in the meantime the continuous changes deployed to the cloud version are finally released as a new version to the on-premise flavor. Dynamics AX 2012 is compatible with both flavors but some specific versions or hotfixes are needed for some combinations. See Dynamics AX Prerequisites for specific details.
** Testing TFS is never been easier. From an implementation perspective, by using VSTS you don’t need to install nor deploy any component yourself as it works as a service; Cost-wise, VSTS is free up to 5 users, more than enough to test with a pilot team, and overall cost has been greatly reduced even if you need to buy more licenses. Furthermore, license is included in Visual Studio Subscriptions (former MSDN subscriptions) so you may have it licensed already!
Published first at “Dynamics AX in the Field”, the blog from the Premier Field Engineering team at Microsoft.