[wpkg-users] Tips for testing new/upgraded packages before general deployment

[Natxo Asenjo]

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
>