Linux – Package version maintenance across multiple servers

Problem: If I spin up a server1 today, all installed packages will be based on current upstream versions. If I spin up server2 tomorrow, again, all installed packages will be based on upstream versions, except this time, within the 24 hour difference between server1 and server2, upstream versions on some packages may have changed. So we end up with server1 and server2 out of sync with respect to installed package versions.

My goal is to keep all servers across the infrastructure at the same "snapshot" version, but still support a regularly scheduled update process.

Example. server1 is snapped today. As part of the snap process I run the following commands:

yum update --downloadonly --downloaddir=/path/to/my/repo/base/v1

yum update --enablerepo=mybaserepo

What this will do is pull down all the rpms based on current upstream versions (snapshot). This allows me to host the rpms from "mybaserepo", so when I update other servers, they can get the rpms directly from my repo, without having to worry about upstream rpms being no longer available.

I was thinking of implementing a monthly upgrade cycle, so v1 was snapshotted on 5.1.2013 and it's now 6.1.13. What I was thinking as a process cycle was this:

• Update all other servers to snapshot version 1
• Update snapshot server to version 2 using yum commands given above

And this cycle repeats monthly. Im my mind this strategy solves two problems:

1. Constantly updating servers to ensure upstream patches are brought in on a consistent basis
2. Not pushing out new package versions without first testing (for 30 days) on the snapshot server

Granted, there is no absolute single answer, as there are many ways to skin a cat. What I am looking for is a commonly implemented, industry accepted practice which directly answer the problem of updating servers, while still ensuring the same versions across all servers within an enterprise environment.