On Wed, 2005-09-07 at 23:21 -0500, Les Mikesell wrote:
> On Wed, 2005-09-07 at 22:39, Greg Knaddison wrote:
> > > Or better yet,
> > > a way to tell it that ....
> > > you want it now to apply exactly the same changes on
> > > an important machine that you tested elsewhere
> >
> > As long as you use specific instructions to yum like "yum install
> > foo.1-3.386" and you have a clean and simple set of conf/repos files,
> > then yum will do a very specific thing. If you have multiple
> > repositories in your configuration and you just say "yum update" then
> > it might not behave exactly as you desire.
>
> If you managed a set of servers running homegrown code that
> may or may not be sensitive to library and utility program
> versions, what steps would you use to keep a test server
> up to date, then after performing any needed application
> testing, to roll out the same changes to the production
> servers in various different locations?
I would use yum to keep the testing system up to date, and use rsync to
copy specific RPM packages to the production server. I would not
install yum on the production server at all if you need to control
things tightly.
yum keeps the RPMs in /var/cache/yum/*/packages/.
Also remember that you need to refresh your testing platform regularly.
By this, I mean that you should boot your test system from a CD,
completely clear its disk, and rsync an exact image of your production
server over. Otherwise, you risk having the two drift apart over time.
When I worked for a large financial institution, changes were tested
locally by the developers, rolled to a "testing" server where they were
tested by others, then rolled to a "staging" server where they were
subjected to a large battery of automated tests, and then finally rolled
to production. Rolls always took place on Friday night. Once a roll
was declared a success, the testing and staging servers were erased and
replaced with near-perfect images of the production servers (the only
difference was that the data sets were trimmed so that only the first
gig of each table was moved). The testing software was kept
in /usr/local, and production servers where not permitted to have
anything in /usr/local. We used to complain that it would take a month
to fix a comma, but it did keep us out of trouble. ;-)
-David
