[wpkg-users] Trying out package upgrades before general roll-out of package

[Chris Wilcox]

I go a step further now - our commercial LAN has a 'CLEAN' build PC which is used to create and test packages.  This PC has an image of a clean XP build on a hidden partition so we can roll back to this very quickly.

 

Since starting with WPKG I have setup an old but more than adequate test PC - I have it in a seperate profile so I can test package rollouts and installs very easily.

 

You could even look into a virtual PC as this is pretty easy to do and also means you can start again with a clean install of the OS by re-loading a clean image.


 
> Date: Sat, 21 Feb 2009 11:40:33 +0100
> From: r.meier at wpkg.org
> To: gaio at sv.lnf.it
> CC: wpkg-users at lists.wpkg.org
> Subject: Re: [wpkg-users] Trying out package upgrades before general roll-out of package
> 
> Hi Marco
> 
> Marco Gaiarin wrote:
> > Mandi! Robin Roevens
> >> We have a general policy here that any new software update/-grade has to 
> >> be tested by 4 to 5 people for some time before it is deployed over all 
> >> affected computers..
> > 
> > Good policy! ;-)
> > 
> > 
> >> But I'm having trouble to do that with WPKG.. :
> > 
> > WPKG does not support this, because the package version/revision are
> > not considered when processing package list, eg there's no way to have
> > the same package with two versions.
> > I've proposed some month ago to add this, and to add the ability to
> > (using a debian term) 'pinpoint' a particular revision.
> > 
> > 
> > There's indeed a hackish but working solution: edit the .XML package
> > recipe upgrading all stuff apart package revision, then edit the
> > %SYSTEMDIR%\wpkg.xml status database of these 4/5 clients, go to the
> > recipe entry and subtract 1 to the package revision.
> 
> I actually prefer another (much less "hackish" solution). I just
> configure my test-systems to use another WPKG installation (might be on
> the same share). Then you can simply upgrade the package on the
> "testbed" installation of WPKG and simply copy over the package
> definition as soon as you know it works. You can even use the same
> software directories/paths if you use the version number within the
> directory name.
> 
> For example
> %SOFTWARE% pointing to \\server\software\
> 
> Then put two versions of a program into this directory:
> \\server\software\Pidgin v.2.5.3
> \\server\software\Pidgin v.2.5.4
> 
> Now install two WPKG versions:
> 
> \\server\wpkg\wpkg.js
> \\server\wpkg\packages\pidgin.xml <-- points to Pidgin v.2.5.3
> \\server\wpkg\...
> 
> \\server\wpkg-testbed\wpkg.js
> \\server\wpkg\packages\pidgin.xml <-- upgrade test for Pidgin v.2.5.4
> \\server\wpkg<...
> 
> 
> This way you can simply test the package on your testbed machines
> (configured to use 'wpkg-testbed'). When you finished testing just copy
> pidgin.xml over to \\server\wpkg\packages\ and it will become productive.
> 
> This way also allows you to test new versions of wpkg.js and other
> modifications without affecting productive users.
> 
> Sometimes it's not necessary to introduce too much complexity into a
> program (wpkg.js) when there is a simple solution provided by the
> operating system already.
> 
> 
> By the way. I am thinking/workging on an extension of WPKG where it
> would be possible to have multiple versions of a package defined in the
> package database and then WPKG either selects the latest one or lets you
> specify a specific one within the profile. However I am personally not a
> friend of this solution because the solution outlined above gives you
> more flexibility like full wpkg.js separation as well as diffetent
> configuration (e.g you might want to use different config.xml / log
> levels on testbed) without even a need to introduce any complex code
> into wpkg.js which potentially creates problems. Every feature
> implemented needs to be supported and fully tested for each following
> release. As more complexity is added as more difficult it gets to
> implement new things or even fix bugs in existing code.
> 
> So give the solution outlined above a try.
> 
> br,
> Rainer
> -------------------------------------------------------------------------
> 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

_________________________________________________________________
Windows Live Messenger just got better .Video display pics, contact updates & more.
http://www.download.live.com/messenger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20090221/15f6e3b8/attachment-0002.html>