Alpha Updates

[Flommer]

After much gnashing of teeth and pulling of hair we have finally gone online with our new Alpha quality system web app. I am still adding functions to the app, but the core is finally there..

My concern now is how to approach the frequent Alpha patches. Sometimes these add features, fix bugs or both. I have also had 1 or 2 patches introduce bugs that killed my in-development app. The fixes came quickly from Alpha, but now that this app is being used by our quality department I must keep downtime to an absolute minimum.

The further development that I'll be doing may cause a problem from time to time, but at least I'm in control of that and can back out of the changes.

Some of our other software is quite behind on patches for the same reason. "If it ain't broke..."

How are the rest of you handling patching Alpha?

Thanks

[mariusm]

Re: Alpha Updates

I don't know about others, but this is what I do:

- I alway keep a copy of the last patch I used before I download the latest patch. That way I don't need to download again a patch that I already had in the computer, in case I need to go back a patch.

- I update my full Alpha AND the Runtime on the development computer. The I check the Runtime for a while. I NEVER install the patch on the users' computers before I know it's OK.

- I only update the users' computers when the patch sorts out some bug we encoutered, when it includes some improvement we need, or when I haven't applied a patch for the last few months. Generally I update the users once every 2-3 months. In the last year I only ONCE found a bug in Alpha that definitely required a patch to be applied on all computers; most of the time patches address problems I never had (or never knew I have :) )

[Steve Wood]

Re: Alpha Updates

If it's running fine at the current patch, don't update unless you hear some patch has increased performance or has some new feature you specifically want to deploy. That is, there is no advantage of doing the patches 'in order', you can always just patch to the latest one.

If you update, update both development and web server at the same time, same patch. Alpha's patch page now has access to all of the older patches (at the very bottom) so I do the patch as soon as it comes out with blind faith that it will work, and revert to an older patch only if I discover or hear of some issue. Somewhere on this forum is a method or ideas on how to auto-patch on some schedule, but I have not deployed that.

[rleunis]

Re: Alpha Updates

In addition what Steve Wood say:

Applying a patch is basically implementing a change through your application system. ITIL (search for it on the internet subtopic Change Management) gives you enough insight how to manage this process, but basically it means that you have to go through a controlled way of applying changes to your system.
Most big companies use the DTAP track approach, where you first apply changes through a Change Management process to different environments:
D: Development - by Programmers
T: Test - System Test by Programmers (does it work as they UNDERSTAND what was wanted)
A: Acceptance - By the End Users (does it work as they MEANT by the Change Request)
P: And when acceptance was ok, you transport it to the production system.
Maybe above is overkill in your situation, but at least 2 environments should be available: one OTA and one Production environment...

1) Refresh OTA with P
2) Apply the change in OTA
3) have it tested there by the end users, and ask formal signoff from them
4) Only then apply the change to the Production system.

A Change can be anything from a request to add new functionality to upgrading because of a patch.

Of course this approach expects great care is taken for good Test Scenarios with expected results to be checked, this especially has an impact for End Users. Since their acceptance will mean they are responsible for taking changes into Production...This also means: not only testing the NEW functionality, but also testing the existing STILL works.
Puts the burdon on end users, instead of the developers...
Or: End users are responsible for the Production System they accepted to use for their information requirement. Including Changes applied to it.
Real live situation is that not only changes will be applied which users ask for. Sometimes you need to upgrade, just because otherwise f.i. support for the tools used is not longer given...In that case it is a change which is forced from outside the user community requests. But still this requires their formal acceptance before taking into production.
regards, Ron

[Flommer]

Re: Alpha Updates

Thanks for the replies!

I am currently the only Alpha development user, but I have a few users that will be hitting the Application Server. That is my production environment in my situation, I suppose.

If I apply changes to my Alpha installation, test the application on the local application server, and then patch the Application Server when all seems well, is that covering myself pretty well? I realize I shouldn't publish any components to the production environment unless Alpha and AS are at the same patch level..

Ron, thank you for the theory background and will do some research to understand it better. I think much of that process would apply especially to how I manage our critical, manufacturing software. Anything with any kind of direct productivity or financial connections to our manufacturing environment seems to deserve that treatment.

Erik

PS here is our website for anybody interested... (Nothing to do with Alpha, sorry!)

www.metalcraftidaho.com

[milesjg]

Re: Alpha Updates

Is there a listing (file/web) where Alpha lists exaclty what was done in a patch. ?

[Steve Wood]

Re: Alpha Updates

The release notes are available from Help > View Release Notes. They do not always contain every little thing that was updated.