I actually second this question. I have been giving some thoughts to
deployment aspect, but apparently I just am not familiar enough with
openwrap yet.
In our case specifically, we can easily be having few dozens of
applications per machine, and be updating several such machines at once
(with same or different apps on each one). Obviously, I'm not excited
with the thought of manually analysing the dependency tree and figuring
out which assemblies exactly need to be updated (and with the manual
copying of them itself of course).
So, I was thinking I could devise something more clever based on
openwrap, central live wrap repository and a version policy to guide the
deployment, but so far the picture is still unclear.
Regards,
Vladimir Okhotnikov
As for CI integration, see the https://github.com/openrasta/openwrap/wiki/Commanding-system page that contains some info on how to run openwrap commands from msbuild scripts useful if you're going to automate building and publishing on a CI server.
1) How do you ensure package compatibility? Do you always specify a full
4-number version in any dependency? Or do you rely on some strict
versioning rules which no one should ever break? How well does it work
in practice - did you have any compatibility incidents?
2) In order to run package from the repository - do you need to
implement custom assembly loading code to look into _cache... ?
Just be ready to nuke packages regularly when teams get it wrong by publishing breaking changes in the revision numbers, that happens quite a bit at the beginning. Hopefully, we'll get some more work done to warn them early, ideally by verifying on publication that a package has the correct compatibility by verifying type changes, and by running all tests with the cross product of compatible versions and fail the publication if tests fail.
As for running packages from the repository, we use the same architecture as openwrap itself, we have a bootstrapper that pre-loads openwrap and its dependencies (the stuff in OpenWrap.PreLoader, copied over), we then load the list of dlls that should be loaded, create a new appdomain and create a small resolver that knows about those dlls and load them as needed. That way you can avoid OpenWrap having to be loaded in the destination AppDomain while still using OpenWrap to resolve dependencies.
-----Original Message-----
From: openwra...@googlegroups.com [mailto:openwra...@googlegroups.com] On Behalf Of Vladimir Okhotnikov
Sent: 29 December 2010 09:44
To: openwra...@googlegroups.com
Subject: Re: [openwrap-devl] CI and deployment