web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Efficiently sync models/packages between DEV environments

(0) ShareShare
ReportReport
Posted on by 113

There are two D365 for Operations development environments: A and B 

A - belongs to LCS impelementation project. 

B - within LCS partner project.

As you might guess, such situation is to avoid more expenses: MS would want us/customer to purchase another DEV box in the LCS implementation project above, but it's more reasonable to use partners' Azure accont.

Both environments are set up against the same VSTS, and version works fine. Build server is not set up yet, though. Early design phase. Solutions are not identical. Reason for this: several ISV solutions are installed in the A (before VSTS was set up), that are not present in B.  

Now I want my B to be as much as possible similar/identical to A. I would like to avoid manually installing the same packages in A. They're some 8..10. What would be the best approach?

  • shall Build environment (when it will be set up) take care of this?
  • LCS can't help me here a lot, since A and B are not in the same LCS project. Or can it?
  • can VSTS synchronize the packages from A to B, by including their model descriptors and eventually other files?
  • or this will never work?

p.s. I have read "Apply a deployable package to a Finance and Operations environment" and have read other forum topics like https://community.dynamics.com/ax/f/33/t/237855 and other.  But most of them are cover topics like "moving changes from DEV to TEST" or "installing a single package in my onebox". But in my case there is a number of packages and two (or several, in future) DEV environments. 

Thank you! 

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Martin Dráb Profile Picture
    237,904 Most Valuable Professional on at

    This is the role of your version control system, i.e. VSTS. The code (including model descriptors) that you check in one environment is visible to everybody else connected to the same system, therefore they can download it from there (Get latest, Get specific version...)

    Build server is used for building code (that you develop on your two development environments) and producing deployable packages for installation to non-development environments. Deployable packages don't contain source code; it's not gonna help with your requirement, which is about development and not deployment.

    LCS has nothing to do with the logic you need.

  • DimanC Profile Picture
    113 on at

    Hi Martin

    Thank you for answer, I appreciate it a lot. You made my understanding of version control system / build server / LCS slightly better :-)

    Regarding setup of version control system and D365 for operations - I remember to have read / heard hints that only custom code (i.e. - non-MS-code) has to be added to version control. So, in my scenario (Standard + ISVs installed on machine A, only standard on machine B), the correct way to get ISVs over to B, would be to add ISV models to version control?

    Thanks!

  • Verified answer
    Martin Dráb Profile Picture
    237,904 Most Valuable Professional on at

    If you have any reference to an ISV solution (code using objects defined there, overlayering, extensions), you must manage them in some way, because your solution wouldn't compile and work without them.

    If an ISV gives you source code, it's up to you to build it in the same way as source code developed by yourself. Add it to VSTS as any other code, despite the fact that it's developed and maintained by somebody else.

    If you get compiled binaries from the ISV, add them to VSTS as well.

    In both cases, you want to make the ISV solution available to developers and build servers, which is what adding to VSTS does. It also allows you to version such solutions together with your code depending on them, therefore you'll be able to easily switch to another version of your application (e.g. in a different branch) and you'll automatically get the right version of ISV solutions.

    I also encourage you to read what Microsoft say about this topic: Manage third-party models and runtime packages by using source control.

    By the way, even hotfixes from Microsoft are added to your version control (see Install a metadata hotfix). But it's true that you shouldn't add all Microsoft code there.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Dráb Profile Picture

Martin Dráb 4 Most Valuable Professional

#1
Priya_K Profile Picture

Priya_K 4

#3
MyDynamicsNAV Profile Picture

MyDynamicsNAV 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans