Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a set of servers with Red Hat on board and an internal software (it is set of many files with configs and so on) that is in permanent development.

There are several types of servers:

  • development
  • testing
  • post-testing
  • production

There are up to 10 servers in each category, but each server works separately and doesn't depend from others. Furtermore in each stream I can have a minor subversions that are tagged in cvs repository. So I can't just build an testing.rpm for all testing servers and prod.rpm for all productions.

Anyway I can see several ways to do that:

  • Make own rpm repository, automatically build a set rpm packages for every server type and its subversion and use a cron to update a package.
  • Use a shell script with own config on each server to do that
  • Make update manually :)

Which one is better? Or all of them are completely wrong and there is another way? :)

share|improve this question
You should probably look into sysadmin automation packages like Puppet, etc. – derobert Sep 6 '12 at 15:41
Actually puppet is the same as shell script for me, because there are a lot of things have to be checked before update/installation. I just can run it via puppet. Or do yo mean something different? – rush Sep 6 '12 at 15:51
What do you mean with Furtermore in each stream I can have a minor subversions that are tagged in cvs repository – Ulrich Dangel Sep 6 '12 at 16:09
@UlrichDangel for example developers made two major changes that couldn't be tested together at the same time, therefore one change will have tag ServerA, second one will have tag ServerB. And the first one should be deployed to the serverA, second one to the serverB. – rush Sep 6 '12 at 16:14
@rush I am not sure about your development and testing process but it sounds like it may or should get improved. Maybe have explicit feature branches and just use your CI system to deploy them to the next dev infrastructure or something like that – Ulrich Dangel Sep 6 '12 at 16:17
up vote 4 down vote accepted

There are multiple things you should consider:

  • Start using a Continuous Integration software for building your software, e.g. Jenkins, Buildbot or other things.
  • Create dedicated repositories for your stages - based on your comment it may help to to the deployment at least for the dev and maybe test stage via your CI tool and for the later stages via automatic updates.
  • Use something like spacewalk or unattended-upgrades or similar tools to keep your systems up to date. Don't use manual cron scripts or login into a system. You can also use puppet instead of spacewalk to ensure you have the latest version of a package installed.
  • Use puppet/chef/… for the configuration and package specification. You can for example simple specify to have the latest package version installed with puppet or add a specific repository to all your testing servers etc.

The most important thing is to automate everything as good as possible. You should use a configuration management system like puppet or chef because this simplifies and automates the deployment of new systems, e.g. you just have to run puppet once and the server is set up like an production system.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.