CI and deployment

2 views
Skip to first unread message

Paul Cowan

unread,
Dec 28, 2010, 2:37:59 AM12/28/10
to openwra...@googlegroups.com
Hi,

I have just finished updating my stack which is reasonably involved via openwrap  and all seems to work, so well done!

At the moment, I am committing the wraps folder and .wrapdesc file into source control which I think is the correct behaviour.

I would like to know your thoughts on how you perceived the wraps folder being used for both CI and deployment.

Previously, I had a lib folder with all the dependency .dll, .pdb and .xml files in each branch which I would copy into the build directory before packaging up for deployment or running tests against.

Would you recommend flattening the /wraps/_cache folder and copying the .dlls into the build directory or what were your thoughts on deployment?

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

Vladimir Okhotnikov

unread,
Dec 28, 2010, 4:11:09 AM12/28/10
to openwra...@googlegroups.com
Hi

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

Sebastien Lambla

unread,
Dec 28, 2010, 10:51:59 AM12/28/10
to openwra...@googlegroups.com
That's how we deploy rich clients where I work currently, a background process simply does an update to the system repository, and we run the app straight from the packages installed on the system.

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.

Vladimir Okhotnikov

unread,
Dec 29, 2010, 4:43:34 AM12/29/10
to openwra...@googlegroups.com
Two questions come to mind:

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... ?

Sebastien Lambla

unread,
Dec 29, 2010, 5:15:20 AM12/29/10
to openwra...@googlegroups.com
The fourth number is never taken into account. Package compat is up to the package builders to keep up their compatible versions by specifying dependency ranges. We recommend the convention I described on my blog for versioning. It's a bit painful at first while teams get used to package compat, but once they have a build server and run their tests against the latest packages as part of the build, it becomes easier.

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

Reply all
Reply to author
Forward
0 new messages