Microsoft Dynamics AX (Archived)

TFS or MorphX VCS for Shared Environment ?

(0) Share

Report

Posted on by whyrony

110

Hi,

We have 5 developers working on an AX 2012 R3 Implementation.

We have a single development server which is used by all 5 developers though rdp.

Please advice which will be the best option for version control.

*This post is locked for comments

I have the same question (0)

All responses (13)

Answers (6)

Verified answer

André Arnaud de Cal... 301,020 Super User 2025 Season 2 on at

Like (1)

Report

Hi John,

TFS has more options compared to MorphX VCS. It would be a matter what exact features you want to use. If it is just about check-out/check-in and have the history available per object, MorphX VCS is sufficient.

Was this reply helpful? Yes No
whyrony 110 on at

Like (0)

Report

Hi Andre,

Thanks for the reply.

We are 5 developers out of which 2 are from the partner company and the rest are in-house developers.

We already has customisation done in VAR, CUS and USR layer as part of the previous implementation efforts.

We didn't used any version control till now.

We as a new implementation team though to do the implementation in CUS layer(by partner developers) and USR layer (by in-house developers).

We just want to avoid conflicts and overriding code changes and to track the changes made.

Was this reply helpful? Yes No
Verified answer

Martin Dráb 237,878 Most Valuable Professional on at

Like (1)

Report

If you develop in two layers, you're essentially building two products and you need at least two environments (one for each layer, each with its own version control repository). From time to time, you have to take code for the CUS layer, copy it to the USR layer and resolve conflicts.

In a single environment, you can't have version control for two different layers and people working in CUS layer wouldn't be able to change correctly objects overlayered in USR.

If you want to uses layers just for isolation of different developers, don't do that. It's not worth the trouble; it's much more complicated than using a single layer (planning,, maintenance of two dev environments and code bases etc.), you artificially prevent people in USR doing some changes like renaming CUS methods (which leads to worse code) and so on.

TFS offers much more than MorphX VCS - a central repository, changesets, security setup, reports, work items tracking, automated builds and so on. Some features would be useful immediately, some gives you more options for your future work (e.g. even if you don't need concurrent development, you might want to need it in future, and you'll simply create a branch, set up a new DEV box and later merge code to the main branch).

If the setup of TFS in a shared environment was that easy as for MorphX VCS, it would be a no-brainer. But it's not. TFS integration in AX doesn't support shared environments, so you would have to make some changes to make it possible. It's worth the effort, in my opinion, but you might see it differently.

Was this reply helpful? Yes No
whyrony 110 on at

Like (0)

Report

Hi Martin,

Thanks a lot for the detailed reply.

You have mentioned not to split the development activity to multiple layers

Can you please help with my concern listed bellow

My current issue is that i have a lot of customisation already done in VAR, CUS and USR layer so

a) How to merge all the customisation into ONE layer ?

b) If we choose to develop in one layer then which will be the preferable one VAR, CUS or USR ?

c) Is it good to create 2 models to differentiate the development done by partner and in-house developer ? Or everyone should use a single model for the same ?

d) You have mentioned that using TFS in a shared environment needs some changes. Can you please provide more details ?

Was this reply helpful? Yes No
Verified answer

Martin Dráb 237,878 Most Valuable Professional on at

Like (1)

Report
You can export elements from one layer (to .xpo) and import it to another layer. Be careful that if the object has customization in a higher layer (e.g. you're connected to CUS but it's customized in USR), the imported code will go there (i.e. to USR, not CUS). You will have to remove such customizations before import.

Different layers have different purposes. Don't put customizations done specifically for you company to the layer for Value-Added Resellers (VAR). If you have a VAR solution in VAR layer, you want to keep it there. Regarding your customizations, CUS (CUStomer) looks like a good choice; it leaves USR available for anything you might need in future (e.g. changes of security elements).

The question is: Do these teams work on completely isolated pieces of work? Don't forget that a single element can't be in two models (inside a single layer) at once. Models are good for splitting functionality to separate logical parts - so far you just mention people from different companies, which is a completely different thing. I expect that you won't be able to use separate models, so you won't have any decision to make. But that's just my expectation without knowing your situation.

Look at my article TFS workspaces in AX2012, for instance.

Was this reply helpful? Yes No
whyrony 110 on at

Like (0)

Report

Hi Martin,

Thanks once again for clarifying my queries.

Regarding models, in my company the previous partner has left the implementation in half way and now we have a new partner continuing with the customisation.

The previous partner has done customisation in multiple layers and in two models and we had some in-house developers who did customisation in different model.

Now since we have a new partner and new in-house team , we are think to clean up the code and start version control, we are trying to move the code from the old development environment to the new environment, but are stuck with various models and layers.

However your points made me to think about combining all the code to one layer (CUS), but what about models can you guide me a bit more ? And mostly the in-house team and partner team works in different requirements hence its almost an isolated piece of work

Was this reply helpful? Yes No

whyrony

110 on at

Like (0)

Report

Let me explain more ,

Please find bellow the model structure used in my company, we changed partner in between AX 2012 R3 Implementation, however its a 20 + company implementation with over 10 companies has already went live. Other companies have complex requirements and the new partner and our company in-house development team is working on it.

We had 2 DEV environment (DEV-1 AND DEV 2), the old partner has done some customisation's in DEV1 environment which is not yet moved to DEV 2.

We are trying to move all the customisation to DEV-2 and perform code cleansing and later release it to production environment.

The new partner and the in-house team will work only on the DEV 2 environment. (Shared environment).

Our team consist of 2 partner and 3 in-house developers working on a shared environment.

Model Structure

Layer	Model name	Model publisher	Model description
var	OP1	OLD PARTNER	OLD PARTNER Standard System
cus	OP2	OLD PARTNER	OLD PARTNER Customisation for COMPANY
usr	INH	IN HOUSE DEV	IN HOUSE DEVELOPMENT TEAM
cus	NP1	NEW PARTNER	NEW PARTNER modifications

The discussions above made me to decide to merge all code and use only one layer(CUS) for development, with TFS as version control . However please help me to decide the model structure also.

I mean do we need separate model or we should work in a single model ?

The development activities performed by partner and in-house team are almost unique

Was this reply helpful? Yes No

Martin Dráb 237,878 Most Valuable Professional on at

Like (0)

Report

Layers and models are used to decompose applications to logical pieces, often with their own lifecycle, development teams etc. I know nothing about you application, so I can't tell you what would be a meaningful way to split it.

If you think that there is no useful split, put it all together to a single module. If you consider the whole code base just a single product (implementation for your company), with no part maintained elsewhere, and that this single product is now pointlessly scattered over four layers, putting it all together sounds like a good idea. Maintaining several layers has some overhead, so if it doesn't give you any advantage, having your applica it would be a waste of resources.

Otherwise start analyzing what parts of your applications represent separate products (e.g. a VAR module usable for more than one customer). Each product usually requires its own development environment, e.g. you don't want to develop a VAR module in a customer environment, because modifications for the customer would prevent you from doing certain modifications, they would confuse your testing, you could intentionally refer to some code for the customer (so the module wouldn't work for other customers) and so on.

Was this reply helpful? Yes No
Verified answer

Denis Macchinetti 16,444 on at

Like (1)

Report

Hi John

You can use more models, e.g. one for the Partner and one for the Internal team.

From my experience, I'll suggest to use one only Model for two reasons:

1-As Martin said, a single element can't be in two models

2- In case you setup the TFS Build process i.e. using the CodeCrib scripts dynamicsaxadmin.codeplex.com, the setup is pretty easy.

Otherwise, for the build purpose, In case of more Models, you must have one Dev Env for each model and use different Branch.

Was this reply helpful? Yes No
Verified answer

Martin Dráb 237,878 Most Valuable Professional on at

Like (1)

Report

Having two teams working on different models in the same layer doesn't work, unless there is a local split of the application to two independent (not overlapping) components.

If some objects are overlapping, it will blow up, because no element can be in two models (in the same layer).

Therefore what's important is the structure of the application, not whether guys doing the work are employed by the end user or a partner.

Was this reply helpful? Yes No