This is a draft
Continuous delivery
Continuous delivery
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