Application Lifecycle Management with AX 2012


Error message

Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of D:\home\site\wwwroot\webapp\includes\

Hey everyone, it's been a few since my last update so I wanted to make it count smiley  We just recently launched our global upgrade of AX 2012 RTM to R3, and it went off without a hitch thanks to a rockstar crew, management and process owners who took charge and made huge commitments to testing, and an organized overall approach.  The first two elements come from working at a great company, and the last comes from careful thought and planning.  It's our approach that I'd like to review with you today.

Application Lifecycle Management

Our primary tooling for ALM and version control is Microsoft Team Foundation Server, commonly known as TFS.  Prior to R3, we kept it very basic: a single TFS folder repository shared by all of our developers.  While this was as simple as it gets, it posed challenging from a multi-developer aspect: we could not check in any objects until they were fully tested and ready for deployment to production.

I used the R3 upgrade effort as an opportune time to engage management and staff alike on the benefits of a more organized, robust Branching design.  Now let me stop here, because there is a word of caution from a wise fellow:
"Your distance from the Main branch is equal to your level of insanity." --anonymous. I think he is saying "save the creativity for the product, and not the branching design."

Branching enables parallel and high-throughput development by giving each activity or developer a snapshot of needed source code, tools, dependencies, and process automation.  Our new branch design is a combination of the ALM Rangers Basic & Code Promotion plans, with some helpful guidance from an AXUG brother over at Sikich and the ALM Rangers.

*Each developer will pull their own branch from the Main branch.  Developers can perform their own development in an isolated branch without impacting others.  Developers are encouraged to check in their source code on a regular basis to prevent loss.

*As code becomes more stable, it is promoted in Visual Studio / TFS to the next branch.  From a developer point of view, this will go from their DEV branch to Main.  Main will be configured with our QA environment.  From Main, it will promote to the PROD branch.

*The promotion check-in of a changeset can be monitored by TeamCity, a continuous integration and deployment application, and automated AX builds can be triggered daily for the next tier (QA,PROD).

Why did branching have such an impact on our upgrade effort?

It allowed us to easily accomplish several objectives at once, all of which are essential in an AX upgrade:

1) Parellel development.  Each developer could work at their own pace to begin analyzing the changes necessary for our CUS layer objects.  The ability to multi-path the project allowed us to hit our 3 month deadline.

2) Traceability.  We were easily able to see if a particular change had  made it to the other environments to determine if it had positive or negative impacts in testing various use cases.

3) Merging.  In some cases, we had developers working on the same retrofit work on the same objects.  We ended up needing to merge these changes together, and the TFS 2012 merge process allowed us to easily see the differences between the two developers and could (constructively!) hash out the details.

In the end, we had a stable R3 codebase in Main, and as additional developers were pulled off supporting RTM all they had to do was pull a fresh branch of R3 and were instantly caught up to the rest of us.  

In my next post, I'll detail how we use TeamCity to perform automated builds of our AX2012 R3 systems!