axStart: How to work with big projects with multi add-ons

[Blog bot]

Источник: http://axstart.spaces.live.com/Blog/...C0A0!212.entry
==============


When you have a big implementation, you have to deal with a lot of suppliers. All these suppliers deliver there own XPO and label files. Now you have to find a nice and structured way to deal with it. I would like to share my experiences in those projects.
 
Let’s start with the suppliers on your project:
1 Microsoft (SYS/SYP).
2 Microsoft localization GLS/GLP. (AX 3.0 ? DIS/DIP)
3 Microsoft fixes (DIS) (AX 3.0 ? XPO)
4 both solutions (GLS/GLP) (customer need GLS runtime license)
5 default solutions from your company (VAR/VAP) (customer need VAR runtime license)
6 your solutions (USR)
 
The reason that I split all suppliers in different layers is this. When an error occur, I’m able to see with supplier is responsible for it. Solution from that supplier are merged in there related layer.
 
GLS/GLP
All external add-ons are merged on this level. Addition MS country localizations that not exist on GLS/GLP level are also merged her. When you start a new project, start with merging the MS countries first. Keep this GLS layer separate for other customers that also need that country. Next merge the both solutions in it. I always start with the countries because in next AX X.0 release, these countries are merged into the GLS layer or higher and my code is obsolete.
 
Most of the time the both solutions have only a US-EN label file. A handy trick is to copy the US-EN label file to the filenames with the country you need. Next edit these new label files with a text editor for translating the English labels.
 
When you merge addition MS countries the can have the same label file name. The solution is to rename the label file with a different name. Also rename the labels in the file to this different name. Finally rename all labels in the XPO whit a text editor.
 
VAR/VAP
In this layer I place the company solutions. The reason I do is that most company don’t have really a release management on there own code. If you have a real internal release management system with helpdesk, hot fixes, etc. I suggest moving your company add-on to GLS/GLP layer.
 
USR/USP
I always develop on the USR layer. I can’t damage any add-on permanently.
 
RELEASING your code:
When I release my code to the customer, I simple export the USR code without labels.
I copy the label files to the release environment and read in the XPO in the VAR/VAP layer.
This VAR layer is send to the customer.
 
Customers that also develop:
Welcome to hell on earth! You are a developer that is responsible for the quality of the code. Now a developer starts working in AX with almost no knowledge on AX. The customer developer is a huge risk. My suggestion to you is this. The customer is allowed to do development in there own isolated development environment. When the customer has completed some code. He sends an XPO to you. You will review it and explain to the customer what is wrong. Finally when the customer has created something acceptable, you merge the customer solution in your own USR layer. When you create a new (VAR) release for that customer, you also release the customer code. So in general no USR code exists in the live environment.
 
Emergency fixes:
Of course you have to make emergency fixes for a customer. These fixes are most of the time quickly created on USR level ad the customer side. This fix will also be implemented in the USR layer of your development environment. So with the next release the USR layer code on the customer side can be removed.


Источник: http://axstart.spaces.live.com/Blog/...C0A0!212.entry