Dynamics 365 Tech Conference Continuous Delivery

This is a draft

Continuous delivery

Continuous delivery

Dynamics 365 Tech Conference General

Document: branch strategically

The main branch – dev and release branches branched off

Try to avoid dev branch for each developer

Main/ dev release10 release15 for each

Set policies:

Going for sprint based version releases

Always get latest before checkin

Shelfsets to nit check in, but store in tfs

Gated checkins – automated testing



Test can be done in devbox-add as user for smoke test


Build definition, one build  VM, creates a deployable package


Continuous integration: check in starts a build, gated checkin also starts build

These are vsts functions, check vsts documentation


Standard ApplicationSuite has models inside-extension package extends it, ISVLegacyCommon to ship the isv binary, overlayering package, (test package for unit test – not to have as part of the deployable package as build result


Splitting the packages have advantages – maintenance, test, build, sharing code-> this is why not only one package

Advantage for Microsoft and Partner, disadvantage for customer because of more stuff (dll) to care about

Can be combined to one solution, but isv maintain them separately


For ci build turn off generate package, deploy report – reason is just to see if still compiles

PackagingExclusions for skip tests in prod build


“There is a wiki, but not yet made available” 😀


Binary in AOT model view are italic


In binary, there is no descriptor. They are also taken care by the build


Dependency graph


LCS tier1-2?


Going to cumulative updates instead of hot fixing


Leave a Reply

Your email address will not be published. Required fields are marked *