You’re offline. This is a read only version of the page.
452
Hello all,
First off this is going to seem like an obvious question to experienced D365 Finance and Operations developers, but I have to ask this. I've done over 100 modules in the MS Learn platform around D365 development and related content including some on Azure and Azure dev ops.
Essentially I'm trying to figure out the best practise and use of a: build machine, dev machine, and test machine all at a tier 1 cloud hosted level.
A few times I read stuff like this:
1: "You must create a deployable package to move code changes from one environment to another. We recommend that you use a build environment to create deployable packages that contain all changes. You can create deployable packages from the development environment." (https://learn.microsoft.com/en-ca/training/modules/explore-technical-architecture-finance-operations/4-source-control)
2: I know we're supposed to: Develop > Get Latest > Build > Check in code > Create a deployable package > Apply to environment (https://learn.microsoft.com/en-us/training/modules/explore-ecosystem-main-components-finance-operations/3-dev-deploy)
But when I think of 1 & 2 above I start to have the impression that the build and deployable package is done on a Cloud Hosted Dev machine to which you -never apply the deployable package or actually run D365 F&O via its own IIS Website. Is that correct?
Or put another way would you have:
Or... can all that happen on the one machine? While learning it is all a bit confusing and overwhelming when you just want to eagerly be productive at work.
Thanks Andrew! You're the best. I've done a lot of MS Learn training but some of these aspects did not connect in my head.
I think the last thing on my mind then in this case is this, and I think it's going to look like a really silly question.. but here goes:
If you build all your code an a machine, does that mean that machine is now running that code when you log on to the environment from it's page in LCS?
Hi Jim,
Code repository should only have your customization code. That being said it's not necessary to change code branch after updating to a new version. The machine you're trying to use to manually create package should connect to the branch which has your customization code.
Thank you so much again Andrew, much appreciated. So three separate cloud hosted environments with purposes of dev, build, and test can work.
Sorry I have a follow on question.
When we deploy a cloud hosted environment, we have to pick an Application Version. Sorry this is going to sound really silly but... how do you take this application version into consideration for operations in visual studio as you move along in time with Microsoft Application version updates?
I can only think of describing my question by way of example scenario:
Lets say I have boxes like the following:
- dev10.0.32
- build10.0.32
- test10.0.32
To which I could map to any branches in my Azure DevOps project following the guidance at learn.microsoft.com/.../new-environments-visual-studio-teams-branch-retail-projects .
So I could have Azure DevOps Project containing these branches:
- Dev
- Main
- ProdRel1
The machine use and branch use would pair up like this I think?
- dev10.0.32 to Dev
- build10.0.32 to ...what? Whichever branch I needed to build from at the moment for testing purposes?
- test10.0.32 - No visual studio use
Then if I needed to test our code at 10.0.33 for instance, would I have to create a new dev10.0.33 and build10.0.33 environments?
I hope this follow on question makes sense. Thanks for any time you can spend sharing your knowledge.
Hi Jim,
Sounds like you're building 1 dev box, 1 build server (manually get the code and create package) and 1 test box. I don't see any problem, but once you have your pipeline configured you can turn your build server to your build agent, so package can be generated automatically.
Hello Andrew,
Thanks for your reply. This helps be understand a bit better, especially when you wrote: "Deploying deployable package to a development box will overwrite the .dll files generated based on your current code, or building your current code will overwrite your deployed files"
Right now I just need to be able to get a dev box running with our 2 ISV packages and our own code extensions. Once I get that running I can look into the Azure DevOps pipeline stuff.
That being said, can I make due for now with the setup I suggested of:
1 Cloud hosted environment to write your extensions and AOT objects, build and if build succeeds.. check in the code to Azure DevOps.
1 Development environment to get latest code from Azure Dev Ops from machine above. Then use this environment to Create a deployable package. Upload that to the Project Asset Library on LCS.
1 Cloud Hosted Tier 1 test environment to which you apply your deployable package from the development machine above so you can test the application functionality in a web browser??
Thanks again for your time.
Hi Jim,
Technically, you can do that on 1 machine, but it doesn't mean you're supposed to do that. Deploying deployable package to a development box will overwrite the .dll files generated based on your current code, or building your current code will overwrite your deployed files. So you should deploy to an environment with no development going on there and use that machine as your test environment.
Normally there're multiple developers working on different customizations on the same code base, if you use your dev box to generate package, you won't be able to do that without interfering each others developing progress. So as Sukrut said, we should leverage the pipeline and build server to create deploy package.
There's only one situation I can think of we want to create deploy package directly from a dev box, that's when we need to deploy a x++ custom script package. See this for details,
Hello Sukrut,
Thanks for the link and your input. The role I have inherited is one where there's only really me that will be developing. The previous admin said they used to use a build pipeline, but since development activity was only done by him, it was a lot of overhead to maintain.
Plus right now.... I'm not looking to learn another whole section of technology.
So, let's say for now we're not using a development pipeline, could you share thoughts on the main content of my question?
Thanks so much, your input would be greatly appreciated.
You can use cloud hosted environments to write your extensions / any sort of development but never use that for creating deployable package. Insated you should be using azure dev ops to create build pipelines to create deployable packages. Documentation is below.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (