[TriLUG] Trust up2date ?

[Adrian Likins]

On Fri, Dec 14, 2001 at 10:45:03AM -0500, Christian J Hedemark wrote:
> Kevin Hunter asks:
> > What do you, the experts, do ?
> 
> Two words:  CHANGE MANAGEMENT
> 
> Tools like up2date are nice, but ultimately you have to have a plan.  Do
> stuff like kernel updates, etc. only after careful planning.  First of all,
> do I need this updated package?  Does it have some bugfix that I need, or
> does it provide some functionality that will make my life better?
> 
> Have and use a staging server to test updates out on.  Run through your plan
> on this staging server (including the back-out plan) and verify that all is
> good.  This machine can be an old discarded Pentium 233 if you aren't
> testing hardware drivers.
> 
> Have and test a back-out plan.  What happens if this upgrade leaves you
> FUBAR?  You will need to be able to roll back to the state your server was
> in before the upgrade.
> 

	I tend to agree with the "use up2date" idea (not that I'm
biased or anything... ;-> ) and the above idea.  

	Having devel/qa/stage/live enviroments (or as many of those
as you can afford) is pretty crucial for production enviroments. For
the most part, I tend to trust the packages that up2date delivers to
not break things, but getting into the habit of staging before live
is pretty critical for availability. Something will break, and you
have to be prepared to fix it quickly. 

	RHN production servers tends to work on the principle of 
any new code or packages goes:

	Individual sandboxes on developers workstations ->
	   integrated devel enviroment ->
             integrated qa envireoment ->
		live

	Ability to back out changes quickly and easily is
pretty important, one of the reasons I'm fond of pushing code
changes out via rpms. Being able to know _exactly_ what version
of code is on a server is equally important. 

	Of course, the closer the qa/devel/stage enviroments
are to the live, the better, but that can be hard to achive.


Adrian