1

I heard about this at a talk over the weekend and it sounded like a great idea for a few reasons I can think of:

  • ensures dependencies are met and not broken (e.g. web app requires specific version of imagemagick)
  • helps make spinning up new servers fast
  • consistency with os packages and ease of deployment
  • (potentially) keeping configs updated with the code so that changes to apache, php, etc. configs are kept current with code dependencies. I can see this is a gray area since it's getting into config management.

1 Answer 1

1

There is nothing wrong with it. It is certainly better than the default. Too many peopel simply check out from version control on each server. However, it is not as good as programs made for web deployments. I personally like using chef with the deploy resouce.

The deploy resouce does a checkout from svn or git into a new directory, symlinks config files, and then changes the symlink your webserver used to point there. This means that if you need to, rollback is as simple as changing a recipe. Then chef just changes a symlink.

It really is all subjective. Chef does have a learning curve but it simplifies many administrative tasks. It also makes it easy to "spin up servers", manage dependencies, and keep configuration files updated. It allows you to combine package management, config management, and system management in one place.

EDIT: Added more information about chef

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .