Ax-Tfs on

Automatic BUILD Processes with TFS and AX 2012 (2/2) (ALM-X)

Tue, 12 Jan 2016 00:00:00 +0100

In the previous article in this series we defined the main process to configure a Microsoft Dynamics AX 2012 Build in TFS, in summary:

Install and configure the necessary TFS components on the build server (Agent, Controller, etc.).
Create a new project with custom activities and the default template.
Upload all of this to the source code repository in TFS or Team Services so the Controller can access them.
Add these references to Visual Studio so it recognizes the new activities.
Create a new Build definition using the downloaded template.

We were left executing this newly created Build definition with all options, activities and default template, and after which we received an error. Frustrating, isn’t it? It may be, but if you think about it, it’s quite logical, let’s see:

Automatic BUILD Processes with TFS and AX 2012 (1/2) (ALM-IX)

Thu, 03 Dec 2015 00:00:00 +0100

In the previous posts of this series we have seen how to configure a TFS server (local or in the cloud) and how to use it to manage our tasks, control the source code and manage versions through branches, among other things. To close the circle we must process all that information, code and versions into something we can deliver to our clients/users.

This is where automatic build and compilation processes come in, called Build processes. Running a Build in TFS is relatively simple if we work with .NET languages, but to do it with AX we’ll have to work a bit beforehand to prepare the environment and install the necessary components on the servers.

Version Control in Microsoft Dynamics AX 2012 Using Team Foundation Server Branches (ALM-VII)

Mon, 19 Oct 2015 00:00:00 +0200

In previous chapters we discussed how to install and configure Team Foundation Server, as well as the possibilities it offers to manage tasks and manage source code from our Microsoft Dynamics AX 2012 instance. We covered basic but essential operations to check code in and out from the server and the resulting benefits, such as storing complete object change history, reviewing object history, reverting to previous versions, discarding unconfirmed changes, etc.

However, there are problems basic source code management cannot solve. For example, in a regular ERP installation, while we provide daily support and small fixes, we are also running larger parallel developments. These parallel streams need to be integrated into production code somehow, but if we use the same server for development and maintenance, we eventually reach a point where all developments must be fully finished before clean and safe production deployment.

Source Code Control with TFS in Microsoft Dynamics AX 2012 (ALM-VI)

Mon, 03 Aug 2015 00:00:00 +0200

In previous chapters of this series we already discussed how to install and/or configure our Microsoft Team Foundation Server instance, and also how to use it to manage our tasks and requirements. This article is the final part focused on the basic integration functionality between Microsoft Dynamics AX 2012 and TFS, so we can start tackling more advanced topics in the next posts.

In this article we will see how to work with TFS for source code version control (VCS), which is the first step to use the most advanced features of the system in terms of ALM capabilities. Basically, version control ensures that any change made to system objects is recorded, including date, author, which other objects were changed at the same time, and why (through check-in comments).

Microsoft Dynamics AX 2012 ALM with Team Foundation Server (ALM-III)

Mon, 03 Sep 2012 00:00:00 +0200

In the previous post in this series, we looked in detail at how to install and perform the basic configuration of a Team Foundation Server 2010 server, and we also assumed the installation of Visual Studio 2008 or 2010 configured with the required updates to connect to this server. Our server was installed and configured with one or more project collections, but no project had been created yet.

In this post we are going to see how a Team Foundation Server 2010 server can help us manage the application lifecycle at a functional level, without getting into technical details, and how this functionality will help us from the earliest project stages when gathering requirements, to the final stages with incident management and change management.

Team Foundation Server 2010 Installation (ALM-II)

Tue, 28 Aug 2012 00:00:00 +0200

In the previous post in this series we discussed the need to follow an application lifecycle management methodology for managing Microsoft Dynamics AX 2012 solutions. We also saw that the main tool to manage the technical side of this lifecycle is Microsoft Team Foundation Server. In this installment we will see how to install and configure the environment to start working.

Prerequisites

I assume we already have a working Microsoft Dynamics AX 2012 environment for testing, which means the following prerequisites are installed:

Microsoft Dynamics AX 2012 Application Lifecycle Management (ALM-I)

Thu, 23 Aug 2012 00:00:00 +0200

Although it may seem curious, even unsettling, a large part of ERP implementation projects, including the Dynamics family in general and Microsoft Dynamics AX in particular, are not run as software projects. Perhaps because of how close the project is to the business, or because the people involved spend most of their time with a business-oriented rather than software-oriented mindset, it is very common to forget, or ignore, that we are implementing software and therefore it is advisable to treat the project as a software project, applying software engineering concepts to manage the software and project management concepts to manage the project.