Dynamics Community Forum Thread Details

Ax 2012 Development Workflow

Hi all

I hope somebody can advise on a workable real-world development workflow. I have read many articles and documents but still have trouble getting my head around this in the real world.

We are re-implementing a live, heavily modified, 2009 installation into 2012. ie a quasi-upgrade (re-code really) with a lot of new developments on top.

For 2009 we had the following workflow, which worked well:

DEV system -> TEST system -> PRE-RELEASE system -> LIVE system

For a particular development (new dev., bug fix etc) we exported an XPO (with IDs) from DEV to TEST, stripping out unwanted modifications line by line during the import when a class, method etc contained changes from other developments.

The changes were tested in TEST and exported, again via XPO, from TEST to PRE-RELEASE, again stripping out anything unwanted during import into PRE-RELEASE.

In PRE-RELEASE the system was integration tested, and when ready we performed a layer copy into LIVE.

All xpo movements were done with IDs included. We relied on developer accuracy in removing unwanted changes during xpo imports which wasn't ideal but mostly worked fine.

So now we're here in 2012!

We are not using separate development environments; rather we are using the MorphX source control in a shared AOS environment.

We have created a single model to store all of our changes.

We want a similar application hierarchy to that used previously - DEV, TEST, PRE-RELEASE and LIVE.

We had planned to use XPOs to move from DEV to TEST (can't export with IDs any more... oh oh!)

From TEST to PRE-RELEASE we aren't yet sure (XPOs? Models? We only have one model!! Should we be using more models?)

We want the ability to have changes being tested in TEST which WON'T be included in the next release to PRE-RELEASE. Is this now unrealistic as we have to move an entire model at a time if we head down that route?

We will import the model store into LIVE from PRE-RELEASE which I guess is the only realistic option.

What do people recommend? Avoid xpos entirely, even for the first stage? Or from the second onwards? What about IDs - this seems like a disaster waiting to happen! Will be later be unable to copy data from LIVE to the earlier environments (also problematic due to the code and source-control both being in the DB!)

Any advice greatly appreciated

Andrew

As far as object IDs go, this problem has been "fixed" by Microsoft with "installation specific IDs", although i think it's more a workaround. In any case, since the objects and code are stored inside the database, a database restore from production down to a test or dev system will include the code, and so also the object IDs.

You can read more about that here:

blogs.msdn.com/.../the-solution-to-the-element-id-problem.aspx

blogs.msdn.com/.../uptaking-installation-specific-ids.aspx

msdn.microsoft.com/.../hh352326.aspx

As far as deploying code, to only move partial code, XPOs is the only way to go. If you use a source control system that supports branching (such as TFS) you can avoid most of the headaches with manual XPO comparison on import, since the branching will tell you of any conflicts of code you are moving that actually belongs to a difference change than the one you are moving.

To move from a pre-release to production, you should move the entire model, or even the entire modelstore (see the whitepaper www.microsoft.com/.../details.aspx ).

You cannot create a model for each customization. Well, you could, but it would be a lot of maintenance, and it would create dependencies (ordering) between the models. An "object" (loosely defined) can only exist in one model within the layer. So if you need to customize the same method for two different customizations, you're already stuck.

Quick Links

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)