On Tue, Apr 5, 2011 at 10:53 AM, Dave Ewart <davee at ceu.ox.ac.uk> wrote: [knip] > In this state, only my testing machines (typically only VMs which I can > snapshot and rollback if/when testing fails) pick up 'app4'. Once I've > got my package definition correct and working for 'app4', I move the > package into the 'typical' profile, like this: > > <profile id="typical"> > <package package-id="app1" /> > <package package-id="app2" /> > <package package-id="app3" /> > <package package-id="app4" /> > </profile> > > <profile id="testing"> > <depends profile-id="typical" /> > </profile> > > I don't think the above is anything revolutionary. It works and works > well. The 'typical' machines only see 'app4' once I'm happy it's ready > for full deployment. > > The issue I have, however, is if I want to test the *upgrade* for an > existing, already deployed app. Let's say, in the above example, I have > an upgrade for 'app2'. I want to be sure that the upgrade works, using > my 'testing' VM, before I make it available to the 'typical' group. > > How do people do that, generally? My main constraint is that there must > be no circumstances under which the 'typical' group can pick up on the > upgrade until I've fully tested it. The 'typical' group should stay > with the non-upgraded 'app2' (or only install the older, non-upraded > version of 'app2' if they've not seen it before). what we do is have serveral (mercurial) repositories: testing, staging, production (for instance). The testing vm's get their configs from \\host\share\wpkg-testing, the staging machines from \\host\share\wpkg-testing and the production from \\host\share\wpkg-production. Every admin has his/her own repo with his/her own vm's that get their settings from yet another folder. So once it's working for the individual admin, he/she pushes it to testing where stuff gets tested, then staged, then in production. ITIL foundation model (kinda). It is a bit messy to start with, but it really helps avoid trouble in the long run. -- natxo > The problem as I see it is that in order to trigger the 'upgrade' rule, > one needs to bump the revision number; I can't see a way to do that only > for the 'testing' group, however. > > Any tips or ideas most welcome! > > (I should mention that I have some ideas about how to do this by hacking > the local wpkg.xml on my testing VM, but this doesn't sound like the > right approach...) > > Thanks, > > Dave. > > -- > Dave Ewart > davee at ceu.ox.ac.uk > Computing Manager, Cancer Epidemiology Unit > University of Oxford / Cancer Research UK > N 51.7516, W 1.2152 > ------------------------------------------------------------------------- > wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ > _______________________________________________ > wpkg-users mailing list > wpkg-users at lists.wpkg.org > http://lists.wpkg.org/mailman/listinfo/wpkg-users > |