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

[Dave Ewart]

Hello,

I've been using WPKG for years now and have found it very useful.
However, I have a question relating to how one tests packages before
making them generally available.

For new package installs, I've got it sorted.  A simplified profiles.xml
looks like this when I'm testing "app4".

<profile id="typical">
  <package package-id="app1" />
  <package package-id="app2" />
  <package package-id="app3" />
</profile>

<profile id="testing">
  <depends profile-id="typical" />
  <package package-id="app4" />
</profile>

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

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